Re: Eiffel and Java

[jsa@alexandria (Jon S Anthony)]

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