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-27 20:02:22 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: aek@vib.usr.pu.ru (Alexander Kopilovitch) Newsgroups: comp.lang.ada Subject: Re: The old "Object.Method" syntax debate Date: 27 May 2003 20:02:21 -0700 Organization: http://groups.google.com/ Message-ID: References: <254c16a.0305210726.485125de@posting.google.com> <3eccdf77$1@epflnews.epfl.ch> <3ecdd296$1@epflnews.epfl.ch> <3ED056CB.8000200@attbi.com> NNTP-Posting-Host: 62.152.82.205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1054090942 16496 127.0.0.1 (28 May 2003 03:02:22 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 28 May 2003 03:02:22 GMT Xref: archiver1.google.com comp.lang.ada:37873 Date: 2003-05-28T03:02:22+00:00 List-Id: Robert I. Eachus wrote: >I really don't like the idea of allowing the Object.Operation format to >Ada. Yeah, the compilers can usually figure it out understand it. But >the potential confusion with component notation is going to confuse >experienced Ada users. (And eventually other O-O language users when >the actually run into component references. 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. 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. >Since the language currently allows defining attributes which are >procedures or functions, why not use the apostrophe notation? Now the >meaning of Object'Operation is clear, even when it is actually >Object'Length or whatever. Probably need a rule about overloading >predefined attributes, but that shouldn't be such a big deal. (They >would be non-overridable declarations in scope.) 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" -:) Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia