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: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: jsa@organon.com (Jon S Anthony) Subject: Re: Real OO (was Choice of OO primitives in Ada95) Date: 1996/02/23 Message-ID: #1/1 X-Deja-AN: 140844274 sender: news@organon.com (news) references: <199602221711.SAA18350@email.enst.fr> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-02-23T00:00:00+00:00 List-Id: In article <4git9e$cqi@stc06.ctd.ornl.gov> kennel@msr.epm.ornl.gov (Matt Kennel) writes: > > Of course, I do not agree. For example, the presence of ONCE functions in > > Eiffel is a kludge to overcome the absence of package initialization that > > is nicely provided by Ada. > > Um maaaaybe, but 'once functions' do what they do with no fuss and with > very clear semantics, without having to define an "elaboration" notion for > packages. > > I'm not sure that's a "kludge" compared to the complexity of package > initialization in Ada. I would agree that "once functions" make sense in the Eiffel design pattern and are not really a kludge. Ada elaboration, of course, fits its design pattern. In this particular case, there really isn't much difference between them in the effects that can be accomplished. Ada elaboration provides for a few more things but that is more due to the fact that packages are not types. > > And as for separating specs and implementations, Ada > > is the only language that does it nicely, without giving up safety. > > This isn't true. Correct, M3 (and M2) for example provide this as well. > You write abstract classes in Eiffel/Sather/C++ which has the spec > (including pre/post/invariant) and write an implementation class which > supports it. > > What is the problem? I don't know. But it is not the same. You still have the interface of the so called "implementation" class which is inextricably hooked to _its_ implementation. The fact is that Meyer (for various reasons) decided _against_ separation of interface and implementation. So, if you are going to argue about this, you should be arguing about whether this choice was "a good idea" (and not pretending that it isn't true). > No. Meyer figured out, quite successfully IMHO, exactly the kinds of > rules that you need to turn "assertions" from just 'check this predicate > and bomb if false' into a powerful *human* protocol "programming by > contract". Well, more or less. To me the real important thing about Eiffel assertions is that they "go in the right place". For example, it is up to the client (enforced via assertions) that the pre-conditions of a "server" are satisfied. > These special rules are exactly what you need so you CAN trust assertions, > because it means that you can put in truly useful checks that don't barf > because of stupidities like the above. Well, more or less. > I think it *is* quite fair to say that Eiffel is more object-oriented---ok > more oriented-around-objects than Ada 95: it's the idee' fixe for Eiffel. >From the standpoint of the 'everything is an "object"' fanat-ahhh-ideology this is clearly true. Actually, it is even more specific than this, viz, all the world's a class. I'm not particularly enamored of this point of view. For one thing it is not obvious what the statement even says, if for no other reason than the fact the central concept is so ill defined as to be meaningless. Of course, this sort of fact has never bothered programmers before - and probably never will. > This doesn't prove 'prima facie' superiority, though I tend to like > Eiffel better. (I've never been convinced about kludges to handle the > 'multiple withing' problem). Check. As for the "withing" problem, well it is clearly an easy and legitimate target. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com