Re: Preventing type extensions

[Cyrille <comar@eu.adacore.com>]

On Sep 29, 6:47 pm, "J-P. Rosen" <ro...@adalog.fr> wrote:
> Thanks for the pointers, but they seem to be quite close to what I am
> suggesting

my point is that those ideas are not new and in fact not that relevant
anymore since they don't solve anything.

> 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 ;-)


> i.e. an abstract operation that is implemented in different ways by
> different objects belonging to a class; i.e. all drawable objects have a
> "paint" method, but each objet has its own way, its own /method/, of
> painting itself. Since this is closely linked to a single member of a
> class, there is no reason to redispatch in such a method.

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.

> 2) There is often a need to provide higher level operations, that are
> /not/ methods, but that are generally implemented by a combination of
> methods: Move=Erase, change position, Draw. Having these as class-wide
> operations rather than redispatching methods guarantees that the same
> behaviour is obtained for all members of the class.

if you are saying that not all subprograms should be methods, I also
think you should have no problem reaching general agreement. It is
true that in Ada, a subprogram that is not a method and acts on a
tagged type better be a class-wide operation.

> 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.

> 4) (this is the topic of my previous messages) If in some cases there is
> a real need for redispatching, it is still possible to follow this
> pattern by subcontracting the dispatching to a class-wide operation that
> does nothing else. But this should be a rare exception.

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.

> Note that this is quite close to Franco's approach, except that I don't
> rely on a specific implementation, thus preserving portability.

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.

> 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.
>
> The benefit of class-wide operations is that they are easily
> recognizable, and therefore my proposed pattern is easily checkable by
> tools (read: will appear in AdaControl as soon as I get around to it).
>
> I don't think it would be as easy in other languages to ensure that the
> profile is followed.

I don't think that (what I understand) from your profile will be very
helpful in a DO-178C context but even if it was, I don't see anything
difficulty in implementing it in other languages since it is just a
matter of differentiating virtual methods (using C++ parlance) from
non-virtual ones or non-methods...