Re: Procedure types and dynamic binding

[sommar@enea.se (Erland Sommarskog)]

Bill Wolfe writes: 
>    I'd think classes would be defined a bit differently!  A package
>    could contain declarations of variables, and we certainly don't want
>    variables included in a class definition (where class is defined as

This is half-true. Thus, we don't want them to be modifyable, but we 
want them to be readable. As far as I am concerned, writeable variable
in packages should be prohibited today, but, alas, wouldn't be a change
to rhyme with backwards compability. It should be avoided anyway.

>> But for inheritance we want all attributes, also those who do not 
>> appear in the specification part (or?), and particulary we probably 
>> want to have access to private types internal structure. 
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>    One of the most fundamental aspects of the ADT paradigm is that
>    an object is known to the outside world only as a type definition
>    and a set of predefined operations.  This provides the independence
>    which allows us to compile specifications and implementations separately.
>    Access to the internal structure of a private type violates the entire
>    concept of a "private" type.  

But can you as ADT designer always find out exactly what I want? Say 
you hand me a linked-list package. I discover that I need to reverse
a list, but does not have such an operation. With Ada today I have
three possibilies:
   1) Write Reverse_list using the existing primitives and place it 
      in my own package.
   2) Write my own extended list package, which calls yours and adds my own 
      Reverse_list.
   3) Re-hack your package, which gives me the possiblility to write a more
      efficient version.
1) has the disadvantge that my code contains something that does not belong
there. 2) Causes redundancy and duplicated declarations. 3) is maybe not 
available for various reasons. It resides in a library I cannot write to, 
and you are holiday. Besides other users would have a lot of recompilation 
triggered just before deliverance and get mad.
  
With inheritance there is a fourth possibility. I can write my extended  
list package to solely inherit all from yours and then add Reverse_list.
Depending if I want to be saved from changes, or need efficiency I
use your primitives, or the implementation.

For more info on this, the "open-closed principle", I once again refer
to Bertrand Meyer's "Object-Oriented Software Construction" where he
discusses these ideas.

>    Seriously though, there *is* a comp.lang.eiffel.  Perhaps you 
>    would feel more at home there rather than in comp.lang.ada.

I feel at home both here and there. Wouldn't say I found that comment
very serious, :-)

>>    Generic
>>...
>>    Package Binary_trees is
>>       ...
>>       Generic
>>          With Procedure Treat(Node : in     Node_type;  
>>                               Data : in out Data_type); 
>>       Procedure Traverse_forward(Tree : Tree_type);
>> 
>> (By the way, an example like the one above should be added to the validation
>> suite if it's not already there. A PC compiler I played with choked on the 
>> code above, and I believe it is/was validated.)
>
>     Why does Node need to be a parameter of Treat?  All you need is
>     something that will treat Data once Traverse_Forward has extracted
>     it from the Node.  Once you've removed the unnecessary parameter,
>     your package should compile perfectly.

You shouldn't work as a compiler. Whether Node is anything useful or
not could be discussed, but it's certainly perfectly legal Ada. If
it is not, tell me why and I write an error report about our Unix
compiler that accepts this. (The use for Node is that the user
may want a quick reference to some data, which he saves somewhere
else.)
-- 
Erland Sommarskog
ENEA Data, Stockholm              This signature is not to be quoted.
sommar@enea.se