Re: Procedure types and dynamic binding

[billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

From article <4223@enea.se>, by sommar@enea.se (Erland Sommarskog):
> 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.

     Proceed with either 2) or 3), whichever you prefer, and use it until
     procedures can be invoked whereby the library is upgraded to satisfy
     this requirement.  Probably there is a mechanism for submitting new
     requirements, and you can go ahead and submit your workaround along
     with your request; the workaround's spec will probably be placed into
     immediate service, perhaps with minor revisions, and the implementation
     will be updated with an optimized version as time permits.  Other users
     will not have recompilation triggered because they are depending on 
     the version which does not provide list reversal, which remains in
     the library.  If no increase in efficiency is possible as a result of
     omitting list reversal, then probably a note will be placed in the
     library saying that programmers should use the new version instead,
     and eventually all software depending on the old version will be 
     rewritten (shifting to the new version in the process), or abandoned,
     and the old version will then be removed from the library.   If your
     local installation prefers, they can instead purchase a more powerful
     version of the ADT, and then apply the same phasing-out procedure
     if there is no efficiency bonus in the less comprehensive ADT.

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

     I have read about this in Meyer's book, and do not agree with it.

     We do not first create the abstract concept of FRUIT and then 
     specialize into APPLEs and ORANGEs; it is the other way around!!

     Additionally, Meyer's approach creates all manner of compilation
     dependencies and inefficiencies, and is in general a very messy
     way to go about doing things.  Instead, let us proceed along the
     lines of a synthesis-oriented approach, as I have described.  

     We should describe FRUIT as an abstraction, and the characteristics
     of FRUIT permit us to decide whether a given real object falls 
     into this class or not.  We can then construct packages which operate
     over the abstraction FRUIT, knowing that our APPLEs and ORANGEs
     will satisfy the abstraction and therefore be compatible with the
     package.  We can even discover PLUMs at a later date, design the
     implementing specification to be compatible with the FRUIT abstraction,
     and then freely insert PLUMs into the stream of FRUIT being handled
     by our packages.  This is a far more natural paradigm; it corresponds
     much more closely to the natural processes of human thought.  

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

    But the problem is that Node is not the user's property; it is the
    property of the generic package.  As such, the user is not free to
    stick arbitrary data in some secret place within the Node.  If the
    user wants to store "a quick reference to some data", then the user
    can define Data as a record with two fields: one will provide the
    REAL data, and the other will provide the user's secret cache.  Then
    the procedure Treat which the user writes can access the user's cache
    freely, and now we see that Node really is a useless parameter.

    (I'm not concerned with the deficiencies of one compiler or another
    as much as I am with the goodness of the ADT; I see no reason why
    the PC should have rejected the code, but I saw a more important
    question which needed to be taken care of first.)



                                         Bill Wolfe

                                  wtwolfe@hubcap.clemson.edu