Re: Preventing type extensions

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

On Oct 5, 7:02 pm, "J-P. Rosen" <ro...@adalog.fr> wrote:

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

Well, "not what you want" is not a criteria for me. The issue is
clearly identified vulnerabilities. Vulnerabilities related to using
method overriding and static dispatch are known and discussed in the
literature.

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

Let me have some doubts... class-wide operations exist in all OO
languages I'm aware of and if there was such a method, it would be
peculiar that nobody had developed it in the standard OO literature in
the last 30 or 40 years...
Note that you use the term redispatching which I'm not too sure what
it means. I'm talking more generally about static dispatch vs dynamic
dispatch in the context of a class hierarchy with method overriding.

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

There will be  (parts of) presentations on that topic at the
"certification together" conference
(http://www.certification-together.com/index.php?
option=com_content&view=article&id=73&Itemid=80)

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

I don't see any reason to see a difference between Ada and C++ in that
respect.

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

Looks to me this is the other way around. for instance, in C++ either
a subprogram is a method or it is what you call a class-wide
operation. That is to say, when your subprogram has a (ref) parameter
of class C, you can pass it an object of any subclass of C and natural
calls to method of that object will dispatch to the appropriate one.
Note also that C++ offers a choice between static dispatch and dynamic
dispatch. My C++ is a bit rusty but here is an example of that. In
this program "subp" is your classwide operation. Here is the output of
the program:

dispatching to m 1
not dispatching to C1::m 1
dispatching to m 3
not dispatching to C1::m 2
-----------
#include <iostream>
using namespace std;
class C1 {
public:
  virtual int m() {return a;}
  C1 () { a = 1; }
  int a;
};

class C2: public C1 {
public:
  virtual int m() {return b;}
  C2 () { a = 2; b = 3;}
  int b;
};

void Subp (C1 &c) {
  cout << "dispatching to m " << c.m() << endl;
  cout << "not dispatching to C1::m "  <<  c.C1::m () << endl;

}

int  main () {

    C1 c1;
    C2 c2;
    Subp (c1);
    Subp (c2);
}