From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!lll-winken!ames!ncar!gatech!hubcap!billwolf From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) Newsgroups: comp.lang.ada Subject: Re: Procedure types and dynamic binding Message-ID: <4038@hubcap.UUCP> Date: 7 Jan 89 22:20:44 GMT References: <4223@enea.se> Sender: news@hubcap.UUCP Reply-To: billwolf@hubcap.clemson.edu List-Id: >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