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: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public From: jsa@organon.com (Jon S Anthony) Subject: Re: Real OO Date: 1996/04/17 Message-ID: #1/1 X-Deja-AN: 148044078 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-04-17T00:00:00+00:00 List-Id: In article donh@syd.csa.com.au (Don Harrison) writes: > Jon S Anthony writes: > > :In article donh@syd.csa.com.au (Don Harrison) writes: >... > :I think you are confused here. Don't start thinking that Eiffel's > :"frozen" feature is the equivalent of a classwide operation. It is > :not. Classwide operations are more general and flexible and cover > :other sorts of ground beyond what you have with simple frozen features. > > Yes, Eiffel's frozen routines alone are not the equivalent of Ada's classwide > operations. The Eiffel analogue is a combination of: > > a) frozen routines, which make a routine classwide for Current, and > b) parameters, all of which are classwide by default, and > c) results of functions, which are classwide by default. > > This provides the same generality and flexibility of Ada's classwide > operations. I don't see how. For one thing clients can't define such things without introducing gratuitous/extraneous classes (I would say this is one of the more important uses). For another, you need some clairvoyance when designing a class in determining the set of features to freeze in order to use them in these sorts of combinations elsewhere. This is a real "no no" ala C++ "virtual" tagging. From what I can tell, Eiffel just plain does not have the equivalent flexible capability here. Again, class wide types and their operations are more like Sather abstract types and ops on them. Eiffel does not have these... > equivalent operations in Eiffel and Ada. They are dispatching wrt > some parameters and classwide wrt others (eg. 2. below). >... Hmmm, actually as I understand the semantics of Like Current, I would say that in general these examples are _not_ equivalent. Like Current seems to require the type of the actual/result must be the same as the type of the specific object on which the particular invocation has been made. No such restriction is true in the Ada case - the result can be any type in the tree rooted at T. Actually, this is a little fuzzy, since there is some other talk in ETL where I think you could read Like Current as allowing for anything _conformant_ to the type of the object on which the invocation has been made. Anyone know the real scoop?? > :> ... and makes the Eiffel approach more flexible (and robust: Ada raises a > :> Constraint_Error exception if the dynamic types of multiple controlling > :> operands differ RM95 3.9.2 (16) ). > : > :Not if you are using classwide types and operations. You can't even > :_have_ multiple controlling parameters in Eiffel so it is certainly no > :more "flexible" here. > Nor would we want to. One operand, Current, is more than adequate to > convey the information in accordance with the OO principle of > uniqueness. Just like I said, Eiffel is less flexible here (but not in some ground shaking way.) > In Ada, with the second, third, fourth, ... and nth > operands of the same specific type controlling dispatching, by the > time the compiler gets to the end of the routine signature, it is > rolling it's eyes and crying: "Good grief, I heard you the first > time!!!" Don, are you really this clueless or are you just being facetious? The reason I say this is that the above doesn't even work as a joke, because it is rooted in an error (instead of a clever observation). >["catcalls" and system validity check problems...] > I suspect it's only a problem in Eiffel because other languages > don't provide that flexibility. Obviously, if Eiffel were more > restrictive, it would not be Actually, Eiffel is (clearly) more restrictive here. It _tries_ to have _less_ things ensured at runtime. And the reason it is a problem is that Eiffel source does not have as much semantic information in it in this area. Ada OTOH, does and has no problem here at all. There was a rather good discussion of this stuff about a year ago. Maybe I can dig that up. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com