Re: Preventing type extensions

["J-P. Rosen" <rosen@adalog.fr>]

Le 30/09/2010 12:08, Cyrille a �crit :
>> Not at all, but I may not have clearly explained my line of reasoning.
>> 1) (Most important) I think that a method should really be a "method", 
> sure a method should be a method. I think it won't be hard to have a
> general agreement on that ;-)
Well... nowadays, many people, and especially the new generation that
has been fed with Java, tends to call "method" every subprogram. I meant
"real methods".

> if there is no reason to use the other methods of the same tagged type
> in the method in question, there is no issue of redispatch anyway. if
> there are such uses and they are done through non-dispatching calls,
> then there are real vulnerabilities and they should be addressed.
> There is no way around that.
Not that fast. You gave convincing examples of that position. I gave (in
my tutorial) convincing examples where redispatching is definitely not
what you want.
My position here is that when redispatching is desired, in most cases,
there is a natural class-wide operation that could handle it. Often
enough to make it a general rule.

[...]

>> 3) I propose to enforce this strict separation, with the added benefit
>> that all dispatching calls are located in class-wide operations, and
>> thus reduce the coverage effort.
> 
> what coverage effort? You seem to believe that "pessimistic testing"
> is mandatory... this is not the case in DO-178C as I explained in a
> former post.
Not mandatory, but one possible solution to coverage.
[...]
> The pattern you suggest (using those wrappers) doesn't address any
> vulnerabilities I am aware of and doesn't help much with coverage
> since there are other better ways to achieve the new related objective
> in the DO-178C.
Since DO-178C is not currently publicly available, I'd be delighted to
have pointers about those "new ways" (if they are different from the
other approaches of OOTiA). Or better, come to the workshop!

> but all this line of reasoning has been overtaken by events. Once
> again, "pessimistic" testing is not the preferred way to address the
> new objective. So trying to make "pessimistic" testing less painful is
> just not that interesting anymore.
Hmmm... pessimistic testing is certainly impractical for C++, but I
wonder if it applies to Ada as well.

>> To conclude about differentiating T and T'Class, the trick you suggest
>>> here is easily implementable in other OO languages. There is nothing
>>> magic in creating a wrapper around a given dispatching call and use
>>> this wrapper at each dispatch point.
Not at all, in other languages either a subprogram is a method (part of
the dispatch table), or it applies to a single type. Class-wide
operations are not dispatched, but still can be applied to a whole
hierarchy. OK, I dismiss "void *" parameters...

----
But my goal is not to force my particular views; the important point is
whether an appropriate profile could be defined for high reliability OO
Ada programs. Such a profile could give a definitive competitive
advantage to Ada in that area.

If you (or anyone else on this list, or even in outer space ;) ) have
good ideas about what to put in that profile, by all means, come to the
workshop, or make a proposal (private mail to me, I'll gather proposals).

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00