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: 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: X-Deja-AN: 193293749 sender: news@organon.com (news) references: <550sm2$sn1@buggy.news.easynet.net> organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1996-10-30T00:00:00+00:00 List-Id: In article <55639c$1of@buggy.news.easynet.net> Sacha@easynet.fr (Vincent WEBER) writes: > Well, I meant that keeping non-OO Ada 83's philosophy made the > language quite hybrid and complicated. Well, not really. You have to realize that Ada83 was nearly OO (as typically used now) anyway. It already had classes, inheritance, and extension (but only for _behavior_). It lacked state extenson and dynamic binding. These were added in Ada95 and the whole type model cleaned up to remove extraneous or other irregularities. > We have both variant records and tagged records, packages are not > true semantic units (you can put just what you want in them), I suppose you really mean that packages are not "first class objects". That was intentional as that aspect is covered by tagged types. It is not at all clear that making them first class even makes any sense (though some have argued that it would). My own reading is that it would be dubious. > and lots of things remain procedural philosophy (pointers to > functions, lots of kinds of types instead of classes, etc...). There is nothing declarative about OO. Eiffel is as procedural as you can get. People, for some reason, can't seem to get this. "Proceduralness" is orthogonal to OO. If you want something non-procedural have a look at a pure logic language (like Mercury). > Moreover Ada fan's claim Ada is the only language that separate > interface from implementation. That can be true... to some extent : > you have to declare the details of a This is just plain wrong. No Ada "fan" with a clue would say this. There are just too many obvious other examples (M2, M3, Clu, ...) > type in the private section of the interface, for instance. That > makes the programmer repeat the same code in both interface and > implementation, whereas the interface is just a subset of the whole > code... Well, this is just plain wrong too. There is no repetition of the "same code in interface and body". I write this stuff everyday and you are just plain in the weeds. > To deffer the implentation of a type, I prefer Eiffel's > deffered classes, that seem more elegant to me, and yet more > powerful (you can have several implementations for the same > interface). Well you are again just plain wrong. The two things solve different problems. Go to dejanews and read an earlier thread abou all this stuff posted to c.l.a and comp.object and c.l.e. It was around springtime with an obvious title. > OO features of Ada 95 are quite difficult to use when > you're not used to them. OO features of Eiffel are quite difficult to use when you're not used to them. So? Yawn. Come on, that is a ridiculous comment. > All the concepts are there, but they're dispatched in lots of > places, you have several ways of doing the same thing, and the > readibility of the code suffer from that The concepts are just a couple and listed in only a couple of places. They are actually very simple. I could list overall basic (what you need in most cases) stuff in just a list with 3 or 4 items in it, each only a couple three sentences long. > I prefer Eiffel's ideology : "One thing in one way". I would add > that Ada's syntax is quite redundant and complicated. For all that > reasons, I founded Ada was heavy. Fine. Those are value judgements. Shrug. I find the Eiffel way restrictive and based on a rather dubious formalism (the only way to organize knowledge is with a classification system and (even worse) it must have MI). Yes, this is "simpler", but it is also inaccurate. > >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. > > Well, to some extent... I admit you can easily use pre and post > conditions in Ada, although maybe in a less elegant way. But in Ada > It may be difficult to emulate an invariant :) Well, here I disagree with the original noter. The type mechanism in Ada does NOT cover pre/post conditions. These are assertions and out of the box Ada only has a subset of this capability. > >You seem to like Java's package mechanism, so it's inclusion in Ada > >can't be it. > > Hum... The Packages in Java are ordered collection in classes. In Ada, they > are... hum, by the way, what are they exactly ? :) Well, I find it hilarious that you don't know what they are yet make claims about them above. It's this sort of stuff that makes the S/N on the net virtually 0. Packages are "merely" containers which can be arranged into extensible hierarchical structures. What they are is not the important bit about them (well maybe a little). It was what you can _do_ with this sort of flexable capability when it is orthogonal to other aspects. So, you can use a package to construct the equivalent structural aspects of a "class" in Eiffel, you can use it to define subsystems, you can use it to function like a Java "package" (or what is basically the same thing) an Eiffle LACE cluster, you can also use them to construct what Eiffel LACE calls "universes", etc. Many useful things - you can dream up your own for that matter. All this with just one simple construct - not several with mushed together semantic confusions. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com