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-21 12:43:26 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!xmission!news-out.spamkiller.net!propagator2-maxim!feed.newsfeeds.com!feed.uncensored-news.com!sn-xit-02!sn-xit-06!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "David C. Hoos" Newsgroups: comp.lang.ada Subject: Re: The old "Object.Method" syntax debate Date: Wed, 21 May 2003 14:43:23 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <254c16a.0305210726.485125de@posting.google.com> <3ECBA778.4070909@crs4.it> X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:37612 Date: 2003-05-21T14:43:23-05:00 List-Id: "Preben Randhol" wrote in message news:slrnbcngsq.aap.randhol+abuse@kiuk0152.chembio.ntnu.no... > David C. Hoos wrote: > > > > It would not make the language ambiguous. Since Him and Her > > are objects of different types, each type would need its own > > version of the Marry procedure, unless they were both derived > > from a common ancestor type which had a class-wide Marry > > procedure. > > No I mean when you read it. Look at the example from the AI: > > > Here is an example of use of the "object.operation" syntax: > > package P is > type T is tagged ... > -- implicit declaration of T'Class > procedure Prim(X : in out T); > procedure Classwide(X : in out T'Class; Y : Integer); > end P; > > with P; > package P2 is > type T2 is new P.T with ... > -- implicit declaration of T2'Class > -- implicit declaration of Prim(X : in out T2); > procedure Prim2(X : in out T2; B : Boolean); > function Prim3(X : T2) return Float; > end P2; > > with P2; > procedure Main is > Obj : P2.T2; > CObj : P2.T2'Class := ... > begin > Obj.Prim; -- call on inherited primitive > Obj.Prim2(True); -- call on primitive > CObj.Prim; -- dispatching call > > Here I get confused, because looking at package P the procedures > available are: > > Prim(X : in out T); and > Classwide(X : in out T'Class; Y : Integer); > > There is no Prim; procedure > > So the student will wonder why do I have to define : > > procedure Prim(X : in out T); > > and not only > > procedure Prim; The parameter is required to identify the "class" of which Prim is an operation (method in classical OO-speak). In Ada, you can have multiple "classes" (hopefully related) within a single package, and there is no class structure to encapsulate both fields and methods of the class. When the fields and methods are encapsulated in a class structure, then you have an implicit controlling parameter (e.g., named "this"). In Ada it needs to be explicit. In this example, X is the object whose state is changed by the operation. > > (Yes I know why, but if the point is to mimic C++ and other OOP languages > syntax this will confuse) > > >From the AI: > > Identifying both the package and the object is to some extent redundant, > and makes object-oriented programming in Ada 95 wordier than necessary, > and/or encourages heavy use of potentially confusing "use" clauses. > Eliminating this redundancy would make object-oriented programming > less-error prone, while also clarifying what object is the controlling > object. > > The last part : "..., while also clarifying what object is the controlling > object." I do not get. For operations on tagged types, only one parameter controls dispatching, and its position doesn't matter. In the case of the example from the AI the call CObj.Prim; Dispatches to P.Prim or P2.Prim, depending on whether CObj is declared as P.T'Class or P2.T2'Class; > > how come I cannot do: > > procedure Main is > True_Or_Not : Boolean; > Object : P2.T2; > begin > > True_Or_Not.Prim2 (Object); > > (I see that B is not defined in out, but if it were) > You cannot do what you write above because Prim2 is not an operation of type Boolean. If B were declared as mode in out, then you would write Object.Prim2 (True_Or_Not); > Besides if one can mix between using the old syntax and the > new type-dot-procedure syntax in the source, wouldn't that lead to quite > hard to read code? Ada already has this notation for protected objects. > > IMHO this is messy, confusing and I neither see the motivation nor > need for it, but I guess I have gotten used to the Ada way :-) Perhaps > somebody else can show my why this is a Good Idea[tm] > > Preben > -- > "... in Ada, you can never have a buffer overflow error. Unless of > course you go very far out of your way to specifically program one > [...] most Ada programmers would consider going out of your way to > construct an Ada program that had a potential buffer overflow not > as a challenge, but as a kind of pornography." - Robert I. Eachus > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada >