Re: Ada Annoyances

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:71c4fdcd-4213-4b84-b852-c8674cfaf717@googlegroups.com...
...
>> In Ada, where redispatching requires explicit work, the vast
>> majority of constructors will never make a dispatching call so there is 
>> very
>> little risk.

>The vast majority? Where does this statistics come from?

Common sense. Constructors shouldn't be doing anything complicated in the 
first place, so there's not much reason for delegation. Even if you do use 
it, dispatching calls are rare in good Ada code. Most of them come from 
factories or global data structures, which are irrelevant here (you're not 
using those things on the constructed object itself within a constructor).

In any case, interfaces and other forms of OOP dispatching are greatly 
overrated; the cases where they can be profitably employed in real-world 
programs are quite rare. (There's much more value from type extension and 
implementation inheritance.)

As I tried to say yesterday, Ada does have a flaw in that allows dispatching 
calls within contructors (and more generally, inside of any primitive 
operations). That requires work of some sort, but it is possible, and it 
shouldn't be. It's too late to fix that in terms of the language, but it's 
easy enough to check with tools like AdaControl.

>I expect programmers to delegate initialization of the base parts to the 
>initialization
> procedure that was already written for the base part, like here:

Surely.

>I'm not sure whether this is majority or minority, but the idiom seems to 
>be intuitive.
>The problem is - even though the view conversion is explicit here, the 
>dispatching
>call in the Base version of Initialize is not and it is there, where the 
>potentially
>unsafe action can occur.

A dispatching call in *any* version of Initialize is a problem, is 
unnecessary, and should have been banned by the language. Don't do it, and 
you'll have no problem to worry about. (And that it true for every 
primitive - "method" in C++ terms.)

...
> These two places can be in separate files, written by different 
> programmers.
> If you decouple explicit from unsafe, this is no longer in the Ada spirit.

Yes, of course if you call broken code, your code will end up broken too. 
Hard to see what could be done about that - it's always possible that the 
base class is written by an incompetent programmer. (Another reason that I 
personally don't think too much of OOP - I want control of everything I 
write -- if I'm going to make a fatal mistake, I at least want it to be 
something that I can improve next time.)

>The complete example (analogous to the C++ example I have written in the 
>other post) is:

I don't buy the usefulness (in real code) of a class-wide Use_Object. My 
experience has been such routines almost always end up needing to be 
primitive (and definitely true in this case).

In any case, we both agree that you shouldn't be able to call Use_Object in 
this case, I suspect our reasons differ but the effect is the same.

>> In any case, this problem is irrelevant.
>
>So guess how did I learn about it...

You wrote some ill-advised Initialize routines? Re-dispatching is almost 
always evil, do it only after VERY careful consideration. (Note that we had 
to fix Pre'Class/Post'Class so they didn't unintentionally cause 
redispatching, as the effect was that a body might not have had the 
precondition it was expecting to have been evaluated).

>> The net takeaway is that a truly type-safe language maybe could be
>> constructed,
>
>Yes. C++ got that part right.

You completely ignored my point about order of initialization, which 
destroys any type-safety up-front. I don't think C++ (or any other 
mainstream language) even tries to get that right...

                               Randy.