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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b6e97963d32ee242 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-28 01:08:01 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!newsfeed.mathworks.com.MISMATCH!newsfeed!btnet-peer0!btnet-feed5!btnet!news.btopenworld.com!not-for-mail From: john@nospam.demon.co.uk (John McCabe) Newsgroups: comp.lang.ada Subject: Re: The old "Object.Method" syntax debate Date: Wed, 28 May 2003 08:07:32 +0000 (UTC) Organization: BT Openworld Message-ID: <3ed46d7a.994560@news.btclick.com> References: <254c16a.0305210726.485125de@posting.google.com> <3eccdf77$1@epflnews.epfl.ch> <3ecdd296$1@epflnews.epfl.ch> <3ED056CB.8000200@attbi.com> NNTP-Posting-Host: host217-37-177-69.in-addr.btopenworld.com X-Trace: sparta.btinternet.com 1054109252 20647 217.37.177.69 (28 May 2003 08:07:32 GMT) X-Complaints-To: news-complaints@lists.btinternet.com NNTP-Posting-Date: Wed, 28 May 2003 08:07:32 +0000 (UTC) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:37879 Date: 2003-05-28T08:07:32+00:00 List-Id: On 27 May 2003 20:02:21 -0700, aek@vib.usr.pu.ru (Alexander Kopilovitch) wrote: >I agree that there may be those troubles with this notation, but there are >significant gains also. Potential confusion with component is one side of >this change, but another side is abstraction step for the concept of component. >In other words, there are cases where it is significant to know that a member >of composite type is really represented by corresponding data element; but >there are plenty of cases where flexibility is more desirable, that is, our >layer should not depend on whether that member actually has consolidated >reprepsentation in memory or it is computed on demand. That is an interesting point and, I believe, directly analogous to the Ada concept of using the same type of parentheses for array acceses and function parameters. > Real problem with this "object notation" for operations in Ada is that there >is no clear understanding where this notation is for good and where it is for >evil. AI-252 mentions "controlling" object, and yes, there are plenty of cases >where we really have some controlling object, and in those cases that "object >notation" often are justified (after all, in such cases this notation actually >carries useful information, explicitly pointing out at the controlling object). >But unfortunately there is very big "grey zone" where controlling objects are >doubtful, and there are many cases without natural controlling objects at all. To be honest I've always had a little difficulty with controlling objects and the Ada 95 syntax. I think this may be because I was trying to get a feel for C++/Java/VB at around the same time as I was learning to use Ada 95 and the object.operation syntax seemed so obvious and simple to me. >I think that it would be wrong to take away that exclusive privilege -- >to introduce attributes -- from the language designers and compiler vendors. >The name space for attributes is too important language resource, it should >not be given out freely for general use. > How about another character instead of apostrophe (or dot) for user-defined >attributes? For example, there is quite popular # (read "join" for this purpose): > Object#Operation >("controlling object" somehow associates with "base" -:) Nah - that's ugly :-) Best Regards John McCabe To reply by email replace 'nospam' with 'assen'