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!ncrlnk!ncrcae!hubcap!billwolf From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) Newsgroups: comp.lang.ada Subject: Re: Ada Language Change: Assignment Overloading Message-ID: <3657@hubcap.UUCP> Date: 23 Nov 88 22:57:59 GMT References: <8811221935.AA21274@grebyn.com> Sender: news@hubcap.UUCP Reply-To: billwolf@hubcap.clemson.edu List-Id: >From article <8811221935.AA21274@grebyn.com>, by karl@grebyn.com (Karl Nyberg): > From: mendal@sierra.stanford.edu (Geoff Mendal) > > 1. Why simply restrict it to assignment? Why not include membership, > short-circuit control forms, indexing, selection, attributes, etc.? > These are all basic operations. I can think of many applications > for overloading membership instead of having to write a function. > Likewise, I can think of applications where an overloading of indexing > would make my code more readable. How I would love to be able to > define my own attributes and use the attribute notation. The point > is that there is nothing special about assignment. Therefore, it > seems to me short-sighted to exclude other basic operations from the > overloading status discussion. First, assignment is a "fundamental" operation; except for attributes, the other things you've suggested apply only to specific classes of ADTs. As for attributes, I think we could live without them if appropriate procedures and functions were defined over the predefined ADTs; having attributes for predefined ADTs and functions for user-defined ADTs is another inconsistency. Procedures and functions are definitely necessary; the attribute mechanism is not. Now another aspect of this problem is the principle that users should be able to define ADTs which are just as powerful as the predefined ADTs; obviously, this is not presently the case with Ada. With regard to attributes, I think elimination of the feature will bring Ada into compliance with this principle, and result in general simplification. Another reason is that assignment procedures need to be invoked as part of the evaluation of a user-defined ADT which is passed by value. No similarly vital function is performed by the other operations suggested. The argument that the operations listed (except assignment and attributes) should be user-programmable with respect to user-defined ADTs is reasonable, but clearly assignment is in a higher class of importance than the others. > 4. Finally, what would an overloading of assignment look like? Would > one parameter have to be mode in and the other mode out? What about > mode in out? What about side effects? Would it be a function or > a procedure, or both? procedure ":=" (FIRST_OBJECT : in out TYPE; SECOND_OBJECT : in TYPE); would seem appropriate.