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: 109fba,953e1a6689d791f6 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,953e1a6689d791f6 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,953e1a6689d791f6 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Eiffel and Java Date: 1996/10/30 Message-ID: #1/1 X-Deja-AN: 193314082 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c++ Date: 1996-10-30T00:00:00+00:00 List-Id: In article donh@syd.csa.com.au (Don Harrison) writes: > Matthew Heaney writes: > > :Ada's type mechanism accomplishes the equivalent of pre- and > :post-conditions, and you don't seem to mind their inclusion in Eiffel, so > :that can't be it. > > It's true that Ada's typing does accomplish some of what assertions offer > but assertions are more general (and useful) than that. For example, it is Right. > :About subprogram calls. C++ or Eiffel programmers call objects this way: > : > : theStack.push (5); > : > :and Ada programmers do this > : > : Push (5, On => The_Stack); > : > :It's not a moral issue which way is better, just a difference in syntax. > :They both do the same thing. > > Yes - not something to lose sleep over. The Ada syntax can be justified > because it is a hybrid language. IMO, the dot notation is preferable for Actually, while it is not multiple dispatching (multi-methods), the syntax does indeed allow several little niceties that the dot notation flubs. It is this stuff that is the "justification" - not any so called "hybrid" aspects. 1) the dot notation makes the operation _look_ like a field of the object but in general this is _not_ true (some OOLs do have per object methods but not the usual ones like Eiffel, C++, Sather, etc...) 2) the dot is asymmetrical and makes many cummutative operations look lopsided. For example, Union(set_a, set_b) = Union(set_b, set_a), and the notation should reflect this (infix would be even nicer here). But in "dot land" you have set_a.Union(set_b) which looks like set_a _has_ the operation and is "special" somehow. 3) the function notation allows Ada to dispatch based on the _result_ of parameter which is a function call. Or has the function dispatch to the right thing based on the other parameters. Bob Duff gave a couple of nice examples of this: Union(My_Set, Singleton(X)), where Singleton's dispatching is the controlling _result_ and _not_ the argument (with X being an integer or something). Here, Singleton would dispatch to the proper version based on the tag of My_Set. (Singleton(X) + Singleton(Y)) * My_Set, where "+" is union and "*" is intersection. Here the tag of My_Set would control the dispatch of the Singleton operations. > it is special. The downside is that symmetric operations do not > appear as such. Well, not really, because you can always regain it > by inventing another class for performing symmetric operations: > > eg. class SET_OPS > ... > union (a, b: SET): SET is ... > intersection (a, b: SET): SET is ... > ... > end Well, sort of... Seems like pretty extraneous futzing to accomplish such a simple and ordinary thing. > In any case, truly symmetric operations are relatively few, IMO. Actually, if you stated this as "for my areas, symmetric ops are relatively few", I could buy it. But in general symmetric operations are all over the place. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com