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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d1df6bc3799debed X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Syntax for tagged record types and class types Date: 1997/05/27 Message-ID: #1/1 X-Deja-AN: 244251602 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1997-05-27T00:00:00+00:00 List-Id: Matthew Heaney (mheaney@ni.net) wrote: : In article <33830D58.6D8F@elca-matrix.ch>, Mats.Weber@elca-matrix.ch wrote: : >So do I. And if tasks and protected types provide that kind of notation, : >why should this not also be true for other constructs ? : Agreed. Selection should be consistent for all objects. The "principle of : uniform reference," and all that. Prefix notation, by which I mean ., is reserved in Ada 95 for calls on "synchronizing" operations. The prefix object is the one controlling the synchronization. Hence, prefix notation is used for task entry calls, and protected operation calls only. In each of these cases, the prefix object is very special -- one must enter the synchronization domain of the prefix object before the operation is performed. Even if there are multiple parameters of the same task or protected type passed to the operation, the synchronization is associated only with the prefix object. For non-synchronizing operations, all parameters are treated symmetrically, and so the "principle of uniform reference" would argue that all such parameters belong inside the parentheses, rather than dangling out front. Furthermore, look at the nasty syntax in a language like C++ for talking about the "mode" of the implicit, prefix parameter. The word "const" is floating about in some unintuitive place in the function declaration. Finally, look at the nastiness associated with binary operators in C++ (and the complete lack of such binary operators in Eiffel and Java). In Ada 95, the "uniform reference" principle of treating all parameters uniformly eliminates all the kludgery associated with binary operations. Note that I am being a bit facetious here. There certainly are some advantages (and disadvantages) to using prefix notation. However, the notion that a single phrase like "uniform reference" can be used to justify one choice over another is a bit of a stretch in my view... : ... : Gee, isn't armchair language design fun? You bet. Of course, if you really want to have fun, try achieving international consensus on your design ... -- For what it is worth, my advice is to avoid using all the fancy syntactic features of your favorite OO language and stick with old function and procedure notation almost everywhere. Constructors, aggregates, and allocators should only be called inside "factory" routines. Operators should be reserved for numeric-ish types like complex numbers, vectors, and matrices. User-defined selectors, array indexers, etc., should be avoided; even using predefined selectors and array indexing should be confined to the implementation of query functions. Use procedures (aka void-returning functions) to change objects, and use functions to query objects. Use a "factory" function or procedure to create new objects. This approach will keep your abstraction "clean" and relatively language neutral, making it amenable to use with CORBA, (D)COM, etc., and other multi-lingual technologies (and people!). All of the "fruit salad" provided by some OO languages saves only a few keystrokes in most cases, and can significantly interfere with the ease with which others can pick up your code and understand it, reuse it, and enhance it. All the above IMVHO... : -------------------------------------------------------------------- : Matthew Heaney : Software Development Consultant : : (818) 985-1271 -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA