Eiffel and Java

Eiffel and Java

[Vincent WEBER]

  Hi everyone... I'm a developer in SITA (Soci�t� Internationale de 
T�l�comunications A�ronautiques). I'm forced to used C++, but I wanted to find 
something better and safer. That's why I had a look at Eiffel (Bertrand Meyer, 
Object-Oriented Software Construction) and Java.
  I appears to me that Eiffel is a great, simple, purely OO language, with nice 
safety features like assertions. Unfortunatly, It has not (yet ?) encounter the 
industrial success It should have. On the other hand, Java is not as much 
powerful as Eiffel, but thanks to Sun's marketing pressure, is very popular. 

   I think it's a pity that Java didn't take all the good stuff from Eiffel, 
that is to say :
  
  - A true genericity mechanism, such as Eiffel constraint genericity.
  I'm afraid it would be too late to include this mecanism in Java now, since 
it would implie re-writing a great part of the API ( The vector class, for 
instance, is not generic, and just simulate a little genericity by accepting 
"Object" parameters).

  - A true and safe multiple inheritance mecanism. Although lots of people 
claim mutliple inheritance is tricky, Eiffel has a safe mecanism to handle the 
issue. Even if Java's interfaces are a nice feature to support multiple 
specification inheritance, there's no way to inherit more than one 
implementation, that can be necessary in some complex cases.
  - "Design By Contract", e.g built-in assertions (Preconditions, 
postconditions and class invariants) that are a great improvment to software 
quality.
  - Covariance, that is much more powerful than Java (and C++) invariance 
principle : in Eiffel attributes and routines in a child class can be redefined 
with children types. The "like" keyword is a simple and powerful way to make 
routines covariant. ( But even if Covariance is natural in lots of problems, 
Sather's contravariant mecanism seem very interesting too, has stronger and 
safer theorical bases... Sather also allow sepation between code inclusion and 
subtyping. Is it cleaner, or just more complicated that the universal 
inheritance mecanism ? any comment ?)
 
  But on the other hand, Java brings very nice (although not new) things to OO 
software construction :

  - Packages to handle name spacing. I think this mechanism (imported from Ada) 
is more elegant than Eiffel's (A separate sub-language, LACE) and is very well 
adapated to distribution of classes in the whole internet.
  - Concurrency, with built-in multithreading. This is very nice, like Ada's 
tasks... But I heard that Bertrand Meyer is working hard on a great concurrency 
mecanism for Eiffel. I hope it will come out soon :)
  - Methods multiple overloading, that allow for instance to have multiple 
constructors with the same name... The Eiffel solution -renaming parent 
methods- seem a little heavy to me. Even if I agree that since Eiffel allow 
multiple inheritance and Covariance for methods, multiple overloading in Eiffel 
would be ackward...
  - Maybe a richer visibily model ( methods can be public or private for the 
whole package, the children classes, the clients...). Eiffel, with its 
principle of openness, does not allow "private" attributes or routines hidden 
to the children classes... but allow to export selectively the features to 
specifically named classes. I don't know where the "truth" is... :)
  - Great networking, database support, great stuff in OO libraries. 
(JavaBeans).


  As a conclusion, I would say that Java had the opportunity to popularize 
Object-Oriented programming, distributing computing on the internet, but it 
lacks Eiffel's power... (Apart the syntax, the two languages are not that much 
different). So... Why don't Eiffel and Java merge ?? Maybe it would be a grat 
opportunity to build THE "perfect language..." (I'm kidding, I know there can't 
be ONE perfect language. But we can take the best of everything that exists to 
build something greater :) )
  This idea might seem heretic to Bertrand Meyer, Eiffel vendors, and Sun :) 
But.. why not ? :) Both part could win in this issue : Java would be much more 
powerful, would rely on stronger theorical bases, and Eiffel would obtain a 
greater industrial success. Let's dream... ISE and Sun working together and 
sharing this market ? :))

  Therefore I would be glad if people from ISE, SIG, Tower, Sun, or any people 
interested in this issue, react -constructively- on what I've just written. I 
would like to get different opinions about OO programming and future of the 
languages. I would also be interested by any information about both  languages 
evolution in the future.
   I'm a strongly-typed believer :) But I would be interested by LISPers 
(CLOSers) and Smalltalkers' reactions as well :)

  By the way, one more thing : I just had a look at ADA 95 and it's "OO" model. 
Even if I admit it is powerful, I think it's very heavy. (The ADA 9X group had 
to keep all the Ada 93 stuff...:)). However, one thing interested me : Ada 
fanatics claim that the dot notation break the symetry of natural operation, 
and that Ada's model of dynamic bindings in all the parameters of a procedure 
is better (that is, writing for instance Add(VectorA, VectorB) instead of 
VectorA.Plus(VectorB). I don't know what to think about this controversy. Any 
idea ?

  Thanks to anyone that would help to elect my favourite language :) Currently, 
I believe that Eiffel is the best OOPL, even if the reality of industry force 
me to live the nightmare of C++ everyday :)

Vincent Weber
Developer - SITA group

Re: Eiffel and Java

[Jean-Michel P. Decombe]

In article <550sm2$sn1@buggy.news.easynet.net>, Sacha@easynet.fr (Vincent
WEBER) wrote:

> different). So... Why don't Eiffel and Java merge ?? Maybe it would be a grat 

I believe that Java is not the death of other languages. Java demonstrates
that it's possible to write a language which is really
platform-independent and "distributed". Nothing prevents Meyer from
writing a new version of Eiffel, totally portable and based on a Virtual
Machine, then port this VM on a large number of platforms, including a
JITC, etc. With the promise of a true platform-independent language, I'm
sure a good number of people would be willing to try it, including myself.
The only problem that remains would be a possible inclusion of this VM in
major browsers. But I believe most browsers will become very customizable
and won't be restricted to Java in the future, plus they will eventually
merge in the OS anyway...

Java is just the beginning of a new era, but it's certainly not the
language who will necessarily win in the end. For now, it's the only one
to do what it does, thus it's the "current" winner...

Xelph

___________________________________________
geo:1705 Cowper Street, Palo Alto, CA 94301
phone:415/327-9563 - fax:415/327-3328
mailto:xelph@acm.org - http://xelph.com/

Re: Eiffel and Java

[David Hanley]

Jean-Michel P. Decombe wrote:
> 
> In article <550sm2$sn1@buggy.news.easynet.net>, Sacha@easynet.fr (Vincent
> WEBER) wrote:
> 
> > different). So... Why don't Eiffel and Java merge ?? Maybe it would be a grat
> 
> I believe that Java is not the death of other languages. Java demonstrates
> that it's possible to write a language which is really
> platform-independent and "distributed". Nothing prevents Meyer from
> writing a new version of Eiffel, totally portable and based on a Virtual
> Machine, then port this VM on a large number of platforms, including a
> JITC, etc. With the promise of a true platform-independent language, I'm
> sure a good number of people would be willing to try it, including myself.
> The only problem that remains would be a possible inclusion of this VM in
> major browsers. But I believe most browsers will become very customizable
> and won't be restricted to Java in the future, plus they will eventually
> merge in the OS anyway...

	I suppose this would work, but I think it would make a lot more sense 
to simply compile eiffel to java byte codes.  If he were to do this, he
could,
with very little work, have eiffel available on a large numer of
platforms
(os/2, windows, unix, mac ) immediately, and take advantage of a lot of
work
alredy done by other  people.

> 
> Java is just the beginning of a new era, but it's certainly not the
> language who will necessarily win in the end. For now, it's the only one
> to do what it does, thus it's the "current" winner...

	Sure... But it's smart to leverage on the gains it has made.

	dave

Re: Eiffel and Java

[Matthew Heaney]

In article <550sm2$sn1@buggy.news.easynet.net>, Sacha@easynet.fr (Vincent
WEBER) wrote:

>  By the way, one more thing : I just had a look at ADA 95 and it's "OO"
model. 
>Even if I admit it is powerful, I think it's very heavy. (The ADA 9X group had 
>to keep all the Ada 93 stuff...:)). However, one thing interested me : Ada 
>fanatics claim that the dot notation break the symetry of natural operation, 
>and that Ada's model of dynamic bindings in all the parameters of a procedure 
>is better (that is, writing for instance Add(VectorA, VectorB) instead of 
>VectorA.Plus(VectorB). I don't know what to think about this controversy. Any 
>idea ?

I guess I would qualify as one of those "Ada fanatics." ;-)

What do you mean by "heavy," exactly?  The entire language, or just the
object-oriented features?  You state that we had keep all the Ada 83
features, but what's your issue with that?  

You don't seem to mind putting threads in Eiffel, so the Ada tasking
mechanism can't be it.

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.

You seem to like generics, so that can't be it.

You seem to like Java's package mechanism, so it's inclusion in Ada can't be it.

What is so heavy, then?

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.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Eiffel and Java

[cosc19z5@bayou.uh.edu]

Jean-Michel P. Decombe (xelph@acm.org) wrote:
: In article <550sm2$sn1@buggy.news.easynet.net>, Sacha@easynet.fr (Vincent
: WEBER) wrote:

: > different). So... Why don't Eiffel and Java merge ?? Maybe it would be a grat 

: I believe that Java is not the death of other languages. Java demonstrates
: that it's possible to write a language which is really
: platform-independent and "distributed". Nothing prevents Meyer from
: writing a new version of Eiffel, totally portable and based on a Virtual
: Machine, then port this VM on a large number of platforms, including a
: JITC, etc. With the promise of a true platform-independent language, I'm
: sure a good number of people would be willing to try it, including myself.

Well in a way this has been done.  Java is valuable not for the "language"
but rather for the virtual machine, and as it stands other languages are
taking the cue, and are translating themselves into Java Bytecode so
you can in fact do the same sort of platform independent programming
that you can do in Java in other languages like Ada, and Smalltalk!

So even with Java as the so-called king, this won't mean the death
of other languages, even in distributed applications, since all
that's needed is to translate the source into Java bytecode.


: The only problem that remains would be a possible inclusion of this VM in
: major browsers. But I believe most browsers will become very customizable
: and won't be restricted to Java in the future, plus they will eventually
: merge in the OS anyway...

Even with browsers using the Java VM this only means that other languages
need to output Java VM code.


: Java is just the beginning of a new era, but it's certainly not the
: language who will necessarily win in the end. For now, it's the only one
: to do what it does, thus it's the "current" winner...

It's just Java bytecode that's doing this, the language itself is
can be changed to whatever is needed and it's being done already.


: Xelph

: ___________________________________________
: geo:1705 Cowper Street, Palo Alto, CA 94301
: phone:415/327-9563 - fax:415/327-3328
: mailto:xelph@acm.org - http://xelph.com/

Ahmed

Re: Eiffel and Java

[Matt Kennel]

David Hanley (david@netright.com) wrote:
: Jean-Michel P. Decombe wrote:
: > 
: > In article <550sm2$sn1@buggy.news.easynet.net>, Sacha@easynet.fr (Vincent
: > WEBER) wrote:
: > 
: > > different). So... Why don't Eiffel and Java merge ?? Maybe it would be a grat
: > 
: > I believe that Java is not the death of other languages. Java demonstrates
: > that it's possible to write a language which is really
: > platform-independent and "distributed". Nothing prevents Meyer from
: > writing a new version of Eiffel, totally portable and based on a Virtual
: > Machine, then port this VM on a large number of platforms, including a
: > JITC, etc. With the promise of a true platform-independent language, I'm
: > sure a good number of people would be willing to try it, including myself.
: > The only problem that remains would be a possible inclusion of this VM in
: > major browsers. But I believe most browsers will become very customizable
: > and won't be restricted to Java in the future, plus they will eventually
: > merge in the OS anyway...

: 	I suppose this would work, but I think it would make a lot more sense 
: to simply compile eiffel to java byte codes.  If he were to do this, he
: could,
: with very little work, have eiffel available on a large numer of
: platforms
: (os/2, windows, unix, mac ) immediately, and take advantage of a lot of
: work
: alredy done by other  people.

What is critically important is that the semantics of the common
Java libraries and object distribution formats (for instance even
Java RMI--'emote method invocation'---in reality full distributed objects),
in the JVM are two-way-compatible with this Eiffel implementation.

Java is important because of the JVM and the presumed availability of a rich
set of services across many computers. 

Fortunately it seems that much of Java's semantics is a subset of Eiffel's.

Tough parts which must be addressed are garbage collection compatibility
(i.e. references from Eiffel-side to Java side and back must be collected
 as 'one'), finalization, and signatures for exceptions.
 
 
I recently recieved an announcement from a computer science group at MIT
about a proposal for parameterized generic types for Java. 


: 	dave

--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 
  I would not, could not SAVE ON PHONE,    |==================================
  I would not, could not BUY YOUR LOAN,    |The US Government does not like
  I would not, could not MAKE MONEY FAST,  |spam either.  It is ILLEGAL!
  I would not, could not SEND NO CA$H,     |USC Title 47, section 227
  I would not, could not SEE YOUR SITE,    |p (b)(1)(C) www.law.cornell.edu/
  I would not, could not EAT VEG-I-MITE,   | /uscode/47/227.html
  I do *not* *like* GREEN CARDS AND SPAM!  |==================================
               M A D - I - A M!

Re: Eiffel and Java

[Alexandre Oliva]

Jean-Michel P Decombe writes:

> In article <550sm2$sn1@buggy.news.easynet.net>, Sacha@easynet.fr (Vincent
> WEBER) wrote:

>> different). So... Why don't Eiffel and Java merge ?? Maybe it would be a grat 

> I believe that Java is not the death of other languages. Java demonstrates
> that it's possible to write a language which is really
> platform-independent and "distributed". Nothing prevents Meyer from
> writing a new version of Eiffel, totally portable and based on a Virtual
> Machine, then port this VM on a large number of platforms, including a
> JITC, etc. With the promise of a true platform-independent language, I'm

I seem to remember having  seen an announcement  of an Eiffel compiler
that generates Java ByteCode, runnable on  any JVM.  Was I dreaming or
this has already become true?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br
Universidade Estadual de Campinas, SP, Brasil

Re: Eiffel and Java

[Larry Kilgallen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]


In article <550sm2$sn1@buggy.news.easynet.net>, Sacha@easynet.fr (Vincent WEBER) writes:
>   Hi everyone... I'm a developer in SITA (Soci�t� Internationale de 
> T�l�comunications A�ronautiques). I'm forced to used C++, but I wanted to find 
> something better and safer. That's why I had a look at Eiffel (Bertrand Meyer, 
> Object-Oriented Software Construction) and Java.

It seems to me that posting this to 9 newsgroups rather than just
the two which are mentioned is guaranteed to lead to pointless
bickering of the "language wars" variety distracting from the
normal purpose of groups like comp.lang.ada.

Larry Kilgallen

Re: Eiffel and Java

[Robert Dewar]

iXelph said

"Java is just the beginning of a new era, but it's certainly not the
language who will necessarily win in the end. For now, it's the only one
to do what it does, thus it's the "current" winner..."

True in some respects, but in other respects, the idea of this kind of
portability is very old, and certainly the pcode version of Pascal ran
on many more different kinds of machines than so far support Java.

Re: Eiffel and Java

[Vincent WEBER]

In article <mheaney-ya023180002810962151220001@news.ni.net>, mheaney@ni.net 
says...

>>  By the way, one more thing : I just had a look at ADA 95 and it's "OO"
>model. 
>>Even if I admit it is powerful, I think it's very heavy. (The ADA 9X group 
had 
>>to keep all the Ada 93 stuff...:)). However, one thing interested me : Ada 
>>fanatics claim that the dot notation break the symetry of natural operation, 
>>and that Ada's model of dynamic bindings in all the parameters of a procedure 
>>is better (that is, writing for instance Add(VectorA, VectorB) instead of 
>>VectorA.Plus(VectorB). I don't know what to think about this controversy. Any 
>>idea ?
>
>I guess I would qualify as one of those "Ada fanatics." ;-)
>
>What do you mean by "heavy," exactly?  The entire language, or just the
>object-oriented features?  You state that we had keep all the Ada 83
>features, but what's your issue with that?  
>

Well, I meant that keeping non-OO Ada 83's philosophy made the language quite 
hybrid and complicated. We have both variant records and tagged records, 
packages are not true semantic units (you can put just what you want in them), 
and lots of things remain procedural philosophy (pointers to functions, lots of 
 kinds of types instead of classes, etc...). 
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 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... 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). 
  OO features of Ada 95 are quite difficult to use when you're not used to 
them. 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. 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.

>You don't seem to mind putting threads in Eiffel, so the Ada tasking
>mechanism can't be it.

You're right... I admit that Ada's built-in multitasking, and that from the 
begining of the language, is very nice :)

>
>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 :)
>
>You seem to like generics, so that can't be it.
>
I agree with you :) Generics are necessary.

>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 ? :)
>
>

Re: Eiffel and Java

[Don Harrison]

Vincent WEBER writes:

:Sather's contravariant mecanism seem very interesting too, has stronger and 
:safer theorical bases... 

Why does Sather use contravariance (apart from the safety issue). You would 
expect more specific actions to require more specific parameters.

: Sather also allow sepation between code inclusion and 
:subtyping. Is it cleaner, or just more complicated that the universal 
:inheritance mecanism ? any comment ?)

What is the purpose of separating interface and implementation inheritance? 
When would you need to inherit an implementation without needing it's interface 
as well (and vice versa)?

[...]

:  By the way, one more thing : I just had a look at ADA 95 and it's "OO" model. 
:Even if I admit it is powerful, I think it's very heavy. (The ADA 9X group had 
:to keep all the Ada 93 stuff...:)). However, one thing interested me : Ada 
:fanatics claim that the dot notation break the symetry of natural operation, 
:and that Ada's model of dynamic bindings in all the parameters of a procedure 
:is better (that is, writing for instance Add(VectorA, VectorB) instead of 
:VectorA.Plus(VectorB). I don't know what to think about this controversy. Any 
:idea ?

Don't mistake Ada's symmetrical syntax for multiple dispatching (binding
driven by more than one parameter). Ada is still single dispatched so for
dispatching operations, the symmetry is syntactic rather than semantic.  


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Eiffel and Java

[Chris Trimble]

I see we meet again, Mr. Bon... I mean, Xelph... :-)

Jean-Michel P. Decombe <xelph@acm.org> wrote:

: I believe that Java is not the death of other languages. Java
: demonstrates that it's possible to write a language which 
: is really platform-independent and "distributed".

 Java hasn't really proved the latter to me; it has yet to show real
platform independence for more than trivial applets (and even a lot of
those).  Python and Tk offer far more powerful multi-platform solution
than Java/AWT.
 
 Here's a good example... Netscape 3.0, on my NT 4.0 box, runs a Java
applet well;  NS 3.0, on my SGI Indigo2 R4400, runs it like an absolute
dog.  The true proof of Java's platform dependence came about two weeks
ago.  Marimba, the epitome of all Java startups, released their new
software for just two platforms -- Win32 and Solaris. Am I supposed to buy
that Sun's solution is really platform independent when their
ex-rock-stars can't deliver for tens of millions of Windows 3.1 users and
Macintosh users?


: Nothing prevents Meyer from writing a new version of Eiffel,
: totally portable and based on a Virtual Machine, then port
: this VM on a large number of platforms, including a JITC, etc.

 Sounds like a good idea to me.  Very good platform independence is
possible if someone is willing to take the time.  Is Eiffel desired on
enough platforms it's not on already to warrant the port is the real
question at hand.  I kinda doubt the answer is a resounding yes.


: Java is just the beginning of a new era, but it's certainly not the
: language who will necessarily win in the end. 

 Thank god.


: For now, it's the only one to do what it does, thus it's the
: "current" winner...

 YUCK!

 Java may have more books on the shelf right now, but I wouldn't even call
it the current top dog language wise... it still isn't much more than a
slightly better and less featureful C++ with really crummy standard
packages.  There are plenty of better solutions that can be had with
Python or even just PERL or Tcl tying some C code together.  Java, as a
language, offers no advantage at all for the serious OO projects being
done in Eiffel, Smalltalk or Ada.  Plus, thanks to NeXT and WO/EOF/D'OLE,
Objective-C seems to be a big contender for Java's potential static
language market.  And, hey, Objective-C is more dynamic than Java... even
as a static language!  :-)

 Java has no real home... it's neither very dynamic nor a very good static
language.  That is why its days are numbered.

 - Chris

Ps -  I've plugged Python twice in this post, but it is really worth
plugging:  http://www.python.org and news:comp.lang.python to find out
more.

Re: Eiffel and Java

[Fergus Henderson]

donh@syd.csa.com.au (Don Harrison) writes:

>What is the purpose of separating interface and implementation inheritance? 

Suppose I have two existing library classes (perhaps supplied by different
vendors) which have some commonality, but don't inherit from a common
base class.  In Sather, one can simply create a new interface and
declare these classes to be instances of this interface, without
modifying the existing code.

(Is that possible in Java?)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Eiffel and Java

[David Petrie Stoutamire]

In article <E00t53.CG2@syd.csa.com.au>,
Don Harrison <donh@syd.csa.com.au> wrote:
>Vincent WEBER writes:
>
>:Sather's contravariant mecanism seem very interesting too, has stronger and 
>:safer theorical bases... 
>
>Why does Sather use contravariance (apart from the safety issue). You would 
>expect more specific actions to require more specific parameters.

Safety is the primary reason (we claim reason enough!), but it also
eliminates runtime checks.  (One can still program in a covariant style by
placing runtime checks explicitly in the code, but contravariance forces
their overhead to be made explicit.)

>: Sather also allow sepation between code inclusion and 
>:subtyping. Is it cleaner, or just more complicated that the universal 
>:inheritance mecanism ? any comment ?)
>
>What is the purpose of separating interface and implementation inheritance? 
>When would you need to inherit an implementation without needing it's interface 
>as well (and vice versa)?

This turns out to be very useful.  Sather 1 strictly separates interfaces
from implementations; abstract classes ("interfaces") can't have code in
them at all.  So entirely different mechanisms are at work for code
inclusion and subtyping.

For example, there is an abstraction in the Sather 1 library called
$SET{T} that has methods like "has(element:T):BOOL".  One can build a new
implementation of sets which conforms to this interface without using any
code from it; and that's pretty much what you want, since the
implementations may have little in common.  If you want some code shared
between them, you build a partial class with that code and include from it
in both implementations.  This way, a third implementation could be built
that doesn't use the shared implementation and it doesn't bother anyone.

Sather-K makes slightly different choices, allowing code in abstract
classes but still allowing code inclusion without subtyping.  I view
Sather-K inheritance as the natural consequence of merging Sather 1
abstract and partial classes into a single construct.

Something similar is possible in Java, where there can be interfaces with
no code (and hence no code inclusion from them).

Our experience is that the differences between these languages don't
affect the code building experience much, but the separation is really
missed as soon as one is forced to go back to a language like C++.

More information on Sather is available at:

   http://www.icsi.berkeley.edu/~sather


   - Dave
-- 
David Stoutamire
http://www.icsi.berkeley.edu/~davids

Re: Eiffel and Java

[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

Re: Eiffel and Java

[Jon S Anthony]

In article <E02IMv.I9M@syd.csa.com.au> 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

Re: Eiffel and Java

[Fergus Henderson]

donh@syd.csa.com.au (Don Harrison) writes:

>Fergus Henderson writes:
>
>:donh@syd.csa.com.au (Don Harrison) writes:
>:
>:>What is the purpose of separating interface and implementation inheritance? 
>:
>:Suppose I have two existing library classes (perhaps supplied by different
>:vendors) which have some commonality, but don't inherit from a common
>:base class.  In Sather, one can simply create a new interface and
>:declare these classes to be instances of this interface, without
>:modifying the existing code.
>
>Sorry. Don't follow. Can you give an example?
>Isn't this creating a superclass rather than separating interface and 
>implementation inheritance?

Yes, that is creating a superclass.  However, I think it would be
impossible to provide this feature in a language like C++ where
interface and implementation inheritence are combined.

The following is from Stephen Omohundro's article about Sather in Dr. Dobb's:
======================================================================
Separate Implementation and Type Inheritance 

In most object-oriented languages inheritance both defines the subtype
relation and causes the descendant to use an implementation provided by
the ancestor. These are quite different notions and confounding them
often causes semantic problems. For example, one reason why Eiffel's
type system is not statically checkable is that it mandates "covariant"
conformance for routine argument types (Meyer, 1992). This means that a
routine in a descendant must have argument types which are subtypes of
the corresponding argument types in the ancestor. Because of this
choice, the compiler cannot ensure argument expressions conform to the
argument type of the called routine at compile time. In Sather,
inheritance from abstract classes defines subtyping while inheritance
from other classes is used solely for implementation inheritance. This
allows Sather to use the statically type-safe contravariant rule for
routine argument conformance.
======================================================================

The following is from Benedict A. Gomes' Sather tutorial.
======================================================================
What is the rationale behind supertyping clauses, and how are they used ? 

You define supertypes of already existing types. The supertype can only
contain routines that are found in the subtype i.e. it cannot extend
the interface of the subtype.

        type $IS_EMPTY{T} > FLIST{T}, FSET{T} is
           is_empty: BOOL;
        end;

The need for supertyping clauses arises from our definitition of
type-bounds in parametrized types. Any instantiation of the parameters
of a parametrized type must be a subtype of those typebounds. You may,
however, wish to create a parametrized type which is instantiated with
existing library code which is not already under the typebound you
want.  For instance, suppose you want to create a class FOO, whose
parameters must support both is_eq and is_lt. One way to do this is as
follows:

 
class BAR{T}  is
        -- Library class that you can't modify
   is_eq(o: T): BOOL;
   is_lt(o: T): BOOL;
end;
type $MY_BOUND{T} > BAR{T} is
    is_eq(o: T): BOOL;
    is_lt(o: T): BOOL;
end;
class FOO{T < $MY_BOUND{T}} is
   some_routine is
        -- uses the is_eq and is_lt routines on objects of type T
        a,b,c: T;
        if (a < b or b = c) then
                ..
        end;
  end;
end;

Thus, supertyping provides a convenient method of parametrizing
containers, so that they can be instantiated using existing classes.
======================================================================

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Eiffel and Java

[Ronald Cole]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> It seems to me that posting this to 9 newsgroups rather than just
> the two which are mentioned is guaranteed to lead to pointless
> bickering of the "language wars" variety distracting from the
> normal purpose of groups like comp.lang.ada.

Excuse me, Larry, but is that a gravy stain on your tie?

-- 
Forte International, P.O. Box 1412, Ridgecrest, CA  93556-1412
Ronald Cole <ronald@ridgecrest.ca.us>    Phone: (619) 499-9142
President, CEO                             Fax: (619) 499-9152
My PGP fingerprint: E9 A8 E3 68 61 88 EF 43  56 2B CE 3E E9 8F 3F 2B

Re: Eiffel and Java

[Don Harrison]

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
possible to specify that *any* boolean condition on a parameter must hold - 
not just that it belongs to a particular family of types or that it's value 
satisfies a range constraint.

Any of a number of Eiffel books provide more info.

: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
Eiffel because it is a pure, single-dispatched language. For such
languages, it makes sense to isolate the dispatching parameter to show that
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

In any case, truly symmetric operations are relatively few, IMO.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Eiffel and Java

[Don Harrison]

Fergus Henderson writes:

:donh@syd.csa.com.au (Don Harrison) writes:
:
:>What is the purpose of separating interface and implementation inheritance? 
:
:Suppose I have two existing library classes (perhaps supplied by different
:vendors) which have some commonality, but don't inherit from a common
:base class.  In Sather, one can simply create a new interface and
:declare these classes to be instances of this interface, without
:modifying the existing code.

Sorry. Don't follow. Can you give an example?
Isn't this creating a superclass rather than separating interface and 
implementation inheritance?


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Eiffel and Java

[James McKim]

In article <E02IMv.I9M@syd.csa.com.au> donh@syd.csa.com.au writes:
>Matthew Heaney writes:

[..]

>
>
>: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
>Eiffel because it is a pure, single-dispatched language. For such
>languages, it makes sense to isolate the dispatching parameter to show that
>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
>
>In any case, truly symmetric operations are relatively few, IMO.

In an article in the 10/94 issue of JOOP, Richie Bielak and I argued that
such features should really be creation routines in class SET.

IMHO, the dot notation and the desire for symmetry are almost orthogonal
issues. For better or for worse many library classes for languages that support
the dot notation have chosen to design intrinsically symmetric operations in
an asymmetric way, but that is not the only way.
 
>
>
>Don.
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Don Harrison             donh@syd.csa.com.au
>
>

Hope this helps,
-- Jim
-- 

*------------------------------------------------------------------------------*
Jim McKim  (860)-548-2458     Teachers affect eternity. They can never tell 
Internet:  jcm@hgc.edu        where their influence stops.

Re: Eiffel and Java

[David L. Shang]

In article <55562c$nkd@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus  
Henderson) writes:
> Suppose I have two existing library classes (perhaps supplied by different
> vendors) which have some commonality, but don't inherit from a common
> base class.  In Sather, one can simply create a new interface and
> declare these classes to be instances of this interface, without
> modifying the existing code.
> 
> (Is that possible in Java?)
> 

No. Java supports only top-down class hierarchy construction
(from superclass to subclasses), but not bottom-up: from
subclasses to superclass.

But Sather's superclass construction is limited to non-parametrerized
classes only.

Transframe provides a more powerful superclass construction that 
can support parameterized classes.

Suppose we have two existing classes

	class Stack #(MemberType: type of any)
	{
		function push(MemberType);
		function pop:MemberType;
	}
	class Queue #(MemberType: type of any)
	{
		function push(MemberType);
		function pop:MemberType;
	}

and later, we decide to have a superclass from them, we can have

	class StackOrQueue #(MemberType: type of any)
			is super Stack, Queue
	{
		function push(MemberType);
		function pop:MemberType;
	}

without modifying the existing subclasses.

Now, we can write polymophic code like:

	x: StackOrQueue;
	if (some_condition) x = Stack#(T1)(); else x:=Queue#(T2)();
	y: any = GetObject();
	assume (y is x#.MemberType) x.push(y); otherwise do_nothing();

We can do the push without knowing whether "x" is a queue or
a stack; we don't know the exact member type either,
the type assurance statement will guarantee that the program
free of run-time type exceptions.

David Shang
	

Re: Eiffel and Java

[Joachim Durchholz]

jsa@alexandria wrote 30.10.96:

> > 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 saw the original Ada definition, and the language struck me as  
interesting and elegant in some places, but somewhat complicated and  
convoluted in others.
From that standpoint, I'd really like to see such a short list of how Ada  
95 is intended to work.

> > 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.

Not really. A single way to do things can be a great advantage, if that  
single way is well done. Just compare the type systems of some RAD  
languages with the simplicity and elegance of Pascal's and (modulo the  
syntactic mess) C.
The Eiffel followers maintain Eiffel does most things right. (I agree to  
the point that I don't have a good solution to the few deficiencies that I  
can make out.)

> 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).

I don't quite follow you here. MI is complicated and a semantic mess in  
C++. It imposes efficiency problems in most languages. None of this  
applies to Eiffel, so there is no reason to use the benefits of MI to  
their full extent.
I agree basing a program's structure on classes only is somewhat dogmatic.  
Clusters retrofit some structure on the Eiffel classes, but I don't see  
anything fundamentally wrong with them.

> Yes, this is "simpler", but it is also inaccurate.

Please clarify. "Inaccurate" in what way?

> 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.

Hmm - in computer science, you usually define the essence of a thing by  
describing what you can do with it :)

> dream up your own for that matter.  All this with just one simple
> construct - not several with mushed together semantic confusions.

On the same grounds, one could say an Eiffel class is a simple and pure  
construct, though it happens to be versatile. I think I see a tendency to  
consider one's pet concepts as simple (seeing the underlying ideas), and  
to consider the opponent's pet concepts as complicated and tricky (seeing  
the various and wildly varying applications the concepts can be used for).  
A good basis for non-productive language wars :(

(Other than that, I tend to agree with the previous post. These are just  
the points that I disagree with.)

Regards,

-Joachim

--
Looking for a new job. Resume available on request. WWW version of resume
available under http://www.franken.de/users/herold/jhd/resume/index.html

Re: Eiffel and Java

[Joachim Durchholz]

jsa@alexandria wrote 30.10.96:

> 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:

Actually, I see this as a *flaw* in Ada.

Yes, it allows one to play some neat and useful tricks with dispatching.

But it also allows totally ambiguous expressions. Example:
Let's have fictitious types INT and LONGINT, with the obvious operator  
definitions
  INT + INT -> INT               (1)
  INT + INT -> LONGINT           (2)
  INT + LONGINT -> LONGINT       (3)
  LONGINT + INT -> LONGINT       (4)
  LONGINT + LONGINT -> LONGINT   (5)
However, this is ambiguous in an expression like
  (INT + INT) + LONGINT
because there are two possible interpretations:
  (INT +(1) INT) +(3) LONGINT
and
  (INT +(2) INT) +(4) LONGINT

I'm not sure how Ada handles such cases. Solution (a) might be a compiler  
error as soon as the compiler detects potentially ambiguous operator (or  
function) declarations, solution (b) might be disambiguating rules.

Solution (a) would make it possible to break existing code by adding  
innocently-looking functions.

Solution (b) is much, much worse. It is not only harder to read  
potentially ambiguous code because you need to know more rules to  
interpret it (and disambiguating rules tend to contain arbitraryness which  
makes remembering the correct rules even harder).
It also introduces subtle changes in semantics - when a new function like  
(3) is introduced, routine calls all over the rest of the system might  
dispatch to the new function, and without an obvious hint to the  
programmer. (You can't even use a string-search tool to find all affected  
calls, because the "+" function is heavily overloaded.)

I'd like to hear wether this is a real problem in Ada or wether I'm seeing  
ghosts here.

Regards,
-Joachim

--
Looking for a new job. Resume available on request. WWW version of resume
available under http://www.franken.de/users/herold/jhd/resume/index.html

Re: Eiffel and Java

[David Bennett]

Jean-Michel P. Decombe wrote:
> 
> Java is just the beginning of a new era, but it's certainly not the
> language who will necessarily win in the end. For now, it's the only one
> to do what it does, thus it's the "current" winner...

Interesting point.  The first person to the market gets 70%
of the market share.  Java managed to be the first to create
a platform independant compiler that will work in web browsers.
I think it will be very hard to get rid of them now, or change it
in any major way.

Saying that Eiffel (because it is a better language) will win is
not strictly true.  Why do people still use Fortran and Cobol?

Wombles,
David.
-- 
---
             David Bennett (A13016@email.mot.com)
                            --*--
   May the butterflies of your mind never obscure the truth

Re: Eiffel and Java

[James McKim]

In article <55639c$1of@buggy.news.easynet.net> Sacha@easynet.fr (Vincent WEBER) writes:
>In article <mheaney-ya023180002810962151220001@news.ni.net>, mheaney@ni.net 
>says...
>

[..]

>
>>
>>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 

Whoa, about the simplest precondition I can think of is related to accessing
the top of a generic stack.

class STACK[G]
...
  top : G is
  require
    not_empty: depth > 0
...

How do you emulate this using types in Ada? 

>Ada, although maybe in a less elegant way. But in Ada It may be difficult to 
>emulate an invariant :)

>>
[..]

Just askin'
-- Jim

-- 

*------------------------------------------------------------------------------*
Jim McKim  (860)-548-2458     Teachers affect eternity. They can never tell 
Internet:  jcm@hgc.edu        where their influence stops.

Re: Eiffel and Java

[Doug Marker]

Robert Dewar wrote:
> 
> iXelph said
> 
> "Java is just the beginning of a new era, but it's certainly not the
> language who will necessarily win in the end. For now, it's the only one
> to do what it does, thus it's the "current" winner..."
> 
> True in some respects, but in other respects, the idea of this kind of
> portability is very old, and certainly the pcode version of Pascal ran
> on many more different kinds of machines than so far support Java.

I agree with your point about the concept. I too used to work with such 
a language - RMCOBOL Pcode - the lang that really got UNIX started in
the commercial world - but you have to be joking to put these into the
same class as Java.

Java has the backing of the biggest and second biggest software
companies in the world (even though the support of the second is very
very dubious). The other older languages were never as mainstream as
Java has already become.

Cheers -  Doug Marker

(PS: Number 1 Software coy = IBM,  Number 2 = Microsoft).

Re: Eiffel and Java

[Doug Marker]

Chris,

This debate really belongs in comp.lang.java - I am sure you would get 
a lot of interest in your opinions there :-)

(lots & lots of interest ;-)

Cheers  -  Doug Marker
Smalltalk & Java solutions developer. 



Chris Trimble wrote:
> 
> I see we meet again, Mr. Bon... I mean, Xelph... :-)
> 
> Jean-Michel P. Decombe <xelph@acm.org> wrote:
> 
> : I believe that Java is not the death of other languages. Java
> : demonstrates that it's possible to write a language which
> : is really platform-independent and "distributed".
> 
>  Java hasn't really proved the latter to me; it has yet to show real
> platform independence for more than trivial applets (and even a lot of
> those).  Python and Tk offer far more powerful multi-platform solution
> than Java/AWT.
> 
>  Here's a good example... Netscape 3.0, on my NT 4.0 box, runs a Java
> applet well;  NS 3.0, on my SGI Indigo2 R4400, runs it like an absolute
> dog.  The true proof of Java's platform dependence came about two weeks
> ago.  Marimba, the epitome of all Java startups, released their new
> software for just two platforms -- Win32 and Solaris. Am I supposed to buy
> that Sun's solution is really platform independent when their
> ex-rock-stars can't deliver for tens of millions of Windows 3.1 users and
> Macintosh users?
> 
> : Nothing prevents Meyer from writing a new version of Eiffel,
> : totally portable and based on a Virtual Machine, then port
> : this VM on a large number of platforms, including a JITC, etc.
> 
>  Sounds like a good idea to me.  Very good platform independence is
> possible if someone is willing to take the time.  Is Eiffel desired on
> enough platforms it's not on already to warrant the port is the real
> question at hand.  I kinda doubt the answer is a resounding yes.
> 
> : Java is just the beginning of a new era, but it's certainly not the
> : language who will necessarily win in the end.
> 
>  Thank god.
> 
> : For now, it's the only one to do what it does, thus it's the
> : "current" winner...
> 
>  YUCK!
> 
>  Java may have more books on the shelf right now, but I wouldn't even call
> it the current top dog language wise... it still isn't much more than a
> slightly better and less featureful C++ with really crummy standard
> packages.  There are plenty of better solutions that can be had with
> Python or even just PERL or Tcl tying some C code together.  Java, as a
> language, offers no advantage at all for the serious OO projects being
> done in Eiffel, Smalltalk or Ada.  Plus, thanks to NeXT and WO/EOF/D'OLE,
> Objective-C seems to be a big contender for Java's potential static
> language market.  And, hey, Objective-C is more dynamic than Java... even
> as a static language!  :-)
> 
>  Java has no real home... it's neither very dynamic nor a very good static
> language.  That is why its days are numbered.
> 
>  - Chris
> 
> Ps -  I've plugged Python twice in this post, but it is really worth
> plugging:  http://www.python.org and news:comp.lang.python to find out
> more.

Re: Eiffel and Java

[Chris]

> they are not ideal.  Other languages are not so vulnerable, because they
are not so 
> widely used for a purpose for which they were not designed, and because
their 
> practitioners won't be seduced by the fact that Java is so similar to
C++.
> 

But *I* am !

Chris

Re: Eiffel and Java

[Jon S Anthony]

In article <1996Oct31.201748.29073@merlin.hgc.edu> jcm@hgc.edu (James McKim) writes:

> In article <55639c$1of@buggy.news.easynet.net> Sacha@easynet.fr (Vincent WEBER) writes:
> >In article <mheaney-ya023180002810962151220001@news.ni.net>, mheaney@ni.net 
> >says...
...
> >>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 
> 
> Whoa, about the simplest precondition I can think of is related to accessing
> the top of a generic stack.
> 
> class STACK[G]
> ...
>   top : G is
>   require
>     not_empty: depth > 0
> ...
> 
> How do you emulate this using types in Ada? 

This is not a particularly good example of not having full assertions in 
standard Ada as it is rather easy to "emulate":

    type Stack is private;
...
    type Depth_Range is new Natural;

    type Stack is record
        Depth : Depth_Range := Depth_Range'First;
        ...
    end record;
...
    function Top (S : Stack) return ...
        Not_Empty : Positive := S.Depth; -- Requires Depth > 0 or CE is raised
...


> Just askin'
> -- Jim

Just answerin'

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Eiffel and Java

[Jon S Anthony]

In article <E06D68.A9r@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> :> 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.
> 
> Ada uses separate interface and implementation for information hiding.
> It has a similar thing to deferred classes in 'abstract types'.

Right.  As was pointed out back in that old thread, to get at the
"separate" spec/impl aspects in Eiffel you would use an "abstract
class" technique.  This doesn't quite work, but it is at least the
proper analogue.


> Actually, it was Autumn. :) The title was 'Real OO'.

Criminey!  A year ago...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Eiffel and Java

[Jon S Anthony]

In article <1996Oct31.162218.8386@schbbs.mot.com> shang@corp.mot.com (David L. Shang) writes:

> In article <55562c$nkd@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus  
> Henderson) writes:
> > Suppose I have two existing library classes (perhaps supplied by different
> > vendors) which have some commonality, but don't inherit from a common
> > base class.  In Sather, one can simply create a new interface and
> > declare these classes to be instances of this interface, without
> > modifying the existing code.
> > 
> > (Is that possible in Java?)
> > 
> 
> No. Java supports only top-down class hierarchy construction
> (from superclass to subclasses), but not bottom-up: from
> subclasses to superclass.

But in general it is _trivial_ to do in Ada.  Note that "inheritance"
aspects need not (and typically will not) even enter into the
"equation" since the functionality is provided by separating the
"module" aspect of class from the "type" aspect and allowing the
module aspect to have separate spec. and impl.


> Suppose we have two existing classes
> 
> 	class Stack #(MemberType: type of any)
> 	{
> 		function push(MemberType);
> 		function pop:MemberType;
> 	}
> 	class Queue #(MemberType: type of any)
> 	{
> 		function push(MemberType);
> 		function pop:MemberType;
> 	}
> 
> and later, we decide to have a superclass from them, we can have
> 
> 	class StackOrQueue #(MemberType: type of any)
> 			is super Stack, Queue
> 	{
> 		function push(MemberType);
> 		function pop:MemberType;
> 	}
> 
> without modifying the existing subclasses.
> 
> Now, we can write polymophic code like:
> 
> 	x: StackOrQueue;
> 	if (some_condition) x = Stack#(T1)(); else x:=Queue#(T2)();
> 	y: any = GetObject();
> 	assume (y is x#.MemberType) x.push(y); otherwise do_nothing();

OK, this example is a little more involved...

with Stacks;  -- Generic
with Queues;  -- Generic
generic
    type Any_Obj is tagged private;
package Stack_Or_Queue

    package S is new Stacks(Any_Obj);
    package Q is new Queues(Any_Obj);

    type Any is access all Any_Obj'Class;
    type Stack_Queue ( S : access S.Stack; Q : access Q.Queue ) is private;
...
procedure Push (Element : Any;  Onto : Stack_Queue);
function  Pop  (SQ : Stack_Queue) return Any;
...
private
    type Stack_Queue ...
...
end Stack_Or_Queue;


with Stack_Or_Queue;
...
    package SQ_T1 is new Stack_Or_Queue(T1);
        package ST1 renames SQ_T1.S;
    package SQ_T2 is new Stack_Or_Queue(T2);
        package QT2 renames SQ_T2.Q;
...
    S : ST1;
    Q : QT2;
...
    if (some condition) then
        declare
            X : SQ_T1(S, null);  -- X is a stack of T1s
            Y : SQ_T1.Any := Get_Object;
        begin
            push(Y, Onto => X);
        end;
    else
        declare
            X : SQ_T2(null, Q);  -- X is a queue of T2s
            Y : SQ_T2.Any := Get_Object;
        begin
            ...
    end if;
...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Eiffel and Java

[Matthew Heaney]

In article <1996Oct31.201748.29073@merlin.hgc.edu>, jcm@hgc.edu (James
McKim) wrote:

>>>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 
>
>Whoa, about the simplest precondition I can think of is related to accessing
>the top of a generic stack.
>
>class STACK[G]
>...
>  top : G is
>  require
>    not_empty: depth > 0
>...
>
>How do you emulate this using types in Ada? 

Perhaps I didn't make my original point clear.  The designers of Ada 95
considered including some precondition/postcondition checking in the
language (as Eiffel does), but opted not to because Ada's rich typing
mechanisms already provide "some of" that.

For example, consider a simple abstract data type for a compass:

package Compasses is

   type Compass is limited private;

   type Heading is digits 6 range 0.0 .. 360.0;

   procedure Set_Heading (C : in out Compass; H : in Heading);
   function Get_Heading (C : Compass) return Heading;
...

The point is that it's a precondition that values for heading lie in the
range [0.0, 360.0], and Ada enforces this.  Just like a precondition it
you're setting the value, and just like a post-condition if you're getting
the value.

That subtype constraints are a form of pre- and post-condition it what I
was trying to say.  Please note that I like Eiffel and think its facilities
for checking assertions, pre-, and post-conditions are way cool and yes, I
really would like something like that in Ada.  Perhaps for the next
revision of the language.

As for how to assert precondition that a stack be non-empty, I can already
do that in Ada:

generic
   type T is private;
package Bounded_Stacks is

   type Stack (Size : Positive) is limited private;

   function Top (S : Stack) return T;

...

private

   type Item_Array is array (Positive range <>) of T;

   type Stack (Size : Positive) is
      record
         Items : Item_Array (1 .. Size);
         Top : Natural := 0;
      end record;

end;

package body Stacks is

   function Top (S : Stack) return T is
   begin
      return S.Items (S.Top);
   end;
...
end;

If the stack is empty, then S.Top = 0 and the call to function Top will
(automatically) raise Constraint_Error, because the array index constraint
was violated.

Just like a precondition.

If you don't like Constraint_Error, then put a handler for it in body of
Top and raise the exception of your choice.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Eiffel and Java

[Matthias Ernst]

Don Harrison (donh@syd.csa.com.au) wrote:

: Why does Sather use contravariance (apart from the safety issue). You would 
: expect more specific actions to require more specific parameters.

: : Sather also allow sepation between code inclusion and 
: :subtyping. Is it cleaner, or just more complicated that the universal 
: :inheritance mecanism ? any comment ?)

: What is the purpose of separating interface and implementation inheritance? 
: When would you need to inherit an implementation without needing it's interface 
: as well (and vice versa)?

All languages that unify inheritance and subtyping enforce that once you
inherit from a class you build a subtype. There are several examples (mostly
with binary methods and the type Self, SAME, like Current or whatever) that
show that it may be the implementation you are interested in but you can't
guarantee subtype relationship.

Say:
class Comparable
is
  "<="(other: Self): Bool is abstract;
  ">="(other: Self): Bool is other <= self end;
  ">"(other: Self): Bool is ~(self <= other) end;
  "<"(other: Self): Bool is other > self end;
end;

You are likely interested to inherit from this class and only implement "<="
but as we all know subtyping is impossible because of the contravariant
position of the Self parameters.

When you look at the examples that claim for covariance you will see that
many are not interested in subtyping, i.e. subsumption, but gather advantage
only from code reuse.

There are already many publications about this topic, you may want to search
for 'binary methods', 'inheritance is not subtyping', 'type matching',
'F-bounded subtyping' and so on. Look for Kim Bruce, Cardelli, Castagna and
many more.

As far as I understand it correctly, it is about what Eiffel's new
typechecking rules with respect to 'polymorphic catcalls' express:
'If it serves your purpose  you may, while inheriting, change parameters or
variable types or access rules in an incompatible (i.e. subtype breaking)
way. But if you try to use subsumption I (the typechecker) will catch you,
requiring programm data flow analysis.'

Sather says:
'You may change what you want when inheriting since for subsumption you must
separately obey the subtype relation that I can check locally.' which I like
better.

One should not forget that Sather's rules also have disadvantages. Because
of the freedom you have it's nearly impossible to check routines once in the
superclass and then inherit them unchecked. The Sather compiler must recheck
every inherited routine in the context of its new class.


-- Matthias

Re: Eiffel and Java

[Don Harrison]

Jon S Anthony writes:

:> 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.

I think Vincent is referring to the fact that the signature of an operation
is repeated in interface and body in such languages (Ada, M3, Oberon ...).
This was also discussed (argued about) in the "Real OO" thread you allude
to below.

:> 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).

Ada uses separate interface and implementation for information hiding.
It has a similar thing to deferred classes in 'abstract types'.

: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.

Actually, it was Autumn. :) The title was 'Real OO'.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Eiffel and Java

[William Clodius]

Matthias Ernst wrote:
> <snip>
> All languages that unify inheritance and subtyping enforce that once you
> inherit from a class you build a subtype. There are several examples (mostly
> with binary methods and the type Self, SAME, like Current or whatever) that
> show that it may be the implementation you are interested in but you can't
> guarantee subtype relationship.
> <snip>

The above restriction is true only if you maintain single dispatch, as
in most object oriented languages. However, I suspect that most
programmers would find that the work required to maintain full
sub-typing relations with multiple dispatch to be more effort than is
justifiable and the result would be semantically error prone even if
nominal type consistency is maintained. Most related objects should not
satisfy the subtype/supertype relationship, and making them satisfy such
a relationship can result in code that does not enforce encapsulation.
Local type consistency, see for example the work on Cecil, may be more
useful

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545

Re: Eiffel and Java

[Ranjan Bagchi]

Chris wrote:
> 
> The point with Java is that it's nearly C++.
> 
> So, even if it's not the best language, the C++ community would choose it
> 
> That's enough to make it a standard !
> 
> Chris

Note:  Smalltalk bias.

I'd think that this kind standard would tend to produce a lot of Java 
code which is just "C++ written in Java".  That is C++ code with 
whatever syntactic tweaking is needed to get it pass the compiler.  

This is similar to what has happened in the C++ community where the joke 
was that there were only 5 real C++ programmers and everyone else was 
just coding C.  There wasn't enough incentive to use the kind of C++ 
idioms that Coplien and Myers write about in their books.

That's what's really neat about languages like Smalltalk where
the language forces programmers to start thinking in Smalltalk's object 
model and produce Smalltalk written in Smalltalk.

-rj

Re: Eiffel and Java

[Matt Kennel]

David L. Shang (shang@corp.mot.com) wrote:
: In article <55562c$nkd@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus  
: Henderson) writes:
: > Suppose I have two existing library classes (perhaps supplied by different
: > vendors) which have some commonality, but don't inherit from a common
: > base class.  In Sather, one can simply create a new interface and
: > declare these classes to be instances of this interface, without
: > modifying the existing code.
: > 
: > (Is that possible in Java?)
: > 

: No. Java supports only top-down class hierarchy construction
: (from superclass to subclasses), but not bottom-up: from
: subclasses to superclass.

: But Sather's superclass construction is limited to non-parametrerized
: classes only.

This isn't true, at least in 1.1.  The following compiles and executes. 

-------------------------------------------------------
-- demonstrate abstract superclass over a parameterized type. 
-------------------------------------------------------
abstract class $OVER{T} > $P{T} is
   feature1(arg:T);
end;

abstract class $P{T} is
  feature1(arg:T);
  feature2(arg:T);
end; 

class CONCRETE{T} < $OVER{T} is
   feature1(arg:T) is #OUT + "In feature\n"; end;
   create:SAME is return new; end; 
end;    

   
class MAIN is
	main is
	  #OUT + "Hello World.\n";
	  
	  ob :$OVER{INT} := #CONCRETE{INT}; 
	  ob.feature1(42);

        end;
end;

--------------------------------
: Transframe provides a more powerful superclass construction that 
: can support parameterized classes.

: Suppose we have two existing classes
: ....

I believe that Sather could express the same concept. 

: David Shang
: 	

--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 
  I would not, could not SAVE ON PHONE,    |==================================
  I would not, could not BUY YOUR LOAN,    |The US Government does not like
  I would not, could not MAKE MONEY FAST,  |spam either.  It is ILLEGAL!
  I would not, could not SEND NO CA$H,     |USC Title 47, section 227
  I would not, could not SEE YOUR SITE,    |p (b)(1)(C) www.law.cornell.edu/
  I would not, could not EAT VEG-I-MITE,   | /uscode/47/227.html
  I do *not* *like* GREEN CARDS AND SPAM!  |==================================
               M A D - I - A M!

Re: Eiffel and Java

[Alan Lovejoy]

Chris wrote:
> 
> The point with Java is that it's nearly C++.
> 
> So, even if it's not the best language, the C++ community would choose it

But it won't kill off or significantly hurt other languages.  Java is a big threat 
to the market share of C++, partly because it panders to the prejudices of C++ coders, 
and partly because it is a better business programming language than C++ (which 
is a better systems programming language than Java).  C++ and C are both systems
programming language that are widely used for business programming, a niche for which 
they are not ideal.  Other languages are not so vulnerable, because they are not so 
widely used for a purpose for which they were not designed, and because their 
practitioners won't be seduced by the fact that Java is so similar to C++.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Eiffel and Java

[Benedict A. Gomes]

In article <55crp0$qn9@dscomsa.desy.de>,
Matthias Ernst <mernst@x4u2.desy.de> wrote:
>
>One should not forget that Sather's rules also have disadvantages. Because
>of the freedom you have it's nearly impossible to check routines once in the
>superclass and then inherit them unchecked. The Sather compiler must recheck
>every inherited routine in the context of its new class.
>

	Though Sather does not do this, it would be easy at the
language level to define a form of code inclusion that avoids this
problem - there have been proposals to this effect- by providing the
sort of encapsulated code inclusion that you get in Java. Since code
inclusion is essentially a syntactic operation, new forms of code
inclusion do not really impact other aspects of the language - they
can be viewed as different kinds of macro operators.  IMHO, this
encapsulated form of code inclusion should actually be the default,
though the current, looser version should still be possible.

ben

Re: Eiffel and Java

[Norman H. Cohen]

Joachim Durchholz wrote:
> 
> jsa@alexandria wrote 30.10.96:
> 
> > 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:
> 
> Actually, I see this as a *flaw* in Ada.
> 
> Yes, it allows one to play some neat and useful tricks with dispatching.
> 
> But it also allows totally ambiguous expressions. Example:
> Let's have fictitious types INT and LONGINT, with the obvious operator
> definitions
>   INT + INT -> INT               (1)
>   INT + INT -> LONGINT           (2)
>   INT + LONGINT -> LONGINT       (3)
>   LONGINT + INT -> LONGINT       (4)
>   LONGINT + LONGINT -> LONGINT   (5)
> However, this is ambiguous in an expression like
>   (INT + INT) + LONGINT
> because there are two possible interpretations:
>   (INT +(1) INT) +(3) LONGINT
> and
>   (INT +(2) INT) +(4) LONGINT

It appears that your are confusing the compile-time issue of overloading
with the run-time issue of dispatching.  Dispatching a function call
based on the required result type can only occur with tagged types, only
when the function call has no PARAMETERS controlling dispatching, and
only when the function call its itself a parameter of some surrounding
dispatching subprogram call.

The issue you address above is overloading, i.e., the declaration of
multiple subprograms with the same name, resolved at compile time based
on the types of parameters and function results.
 
> I'm not sure how Ada handles such cases. Solution (a) might be a compiler
> error as soon as the compiler detects potentially ambiguous operator (or
> function) declarations, solution (b) might be disambiguating rules.

Ada uses solution (a), but provides mechanisms by which a programmer can
provide disambiguating hints.  In practice, most of the time,
overloading just "does the right thing" that a programmer would naively
expect, and provides a succinct, natural notation.  Occasionally, a
programmer is surprised by an error message indicating that his
expression is ambiguous, in which case he adds disambiguating
information (such as enclosing an operand in a "qualified expression"
indicating its type), obtaining a slightly less succinct but unambiguous
expression.  Thus, if I1 and I2 are of type Integer and LI is of type
Long_Integer and, after declaring the five versions of "+" in your
example you write the expression I1+I2+LI (in a context where a
Long_Integer value is expected), the compiler will reject the expression
as illegal.  You can disambiguate the expression by writing either

   Integer'(I1+I2) + LI

or

   Long_Integer'(I1+I2) + LI

depending on which you mean.

It is indeed possible for a programmer to increase the likelihood of
ambiguities by creating too many overloaded functions involving the same
types.  Your example is not a good one because generally accepted Ada
style is to introduce multiple integer types only to reflect multiple
abstract notions, e.g. screen coordinates and port numbers; on the
occasions when it is necessary to intermix multiple  types, a good Ada
programmer writes an explicit conversion--

   LI2 := Long_Integer(I) + LI1;  
      -- I of type Integer; LI1 and LI2 of type Long_Integer

-- rather than declaring a version of "+" with a Long_Integer left
operand, an Integer right operand, and a Long_Integer result.  A better
example is a type Rational, an abstract data type for rational numbers
(probably implemented in terms of an integer numerator and a positive
integer denominator in lowest terms).  The usual arithmetic operators
can be overloaded for this type, to take one or two Rational operands
and produce a natural result.  This is a very natural and appropriate
use of overloading, allowing one to write

   A(I,J) := A(I,J) - A(I,I)*A(Pivot_Row,J);

rather than

   A(I,J) := 
      Rational_Difference
         (A(I,J),
          Rational_Product(A(I,I), A(Pivot_Row, J)));

It doesn't get you into trouble into you decide that you would also like
to overload "/" to act as a constructor for type Rational, taking two
operands of type Integer and returning a Rational result.  Now the
statement

   R := (I1/I2) / (I3/I4);
      -- R is of type Rational; I1, I2, I3, and I4 are of type Integer

becomes ambiguous.  It can be disambiguated by writing any of the
following:

   R := Rational'(I1/I2) / (I3/I4);
   R := (I1/I2) / Rational'(I3/I4);
   R := Rational'(I1/I2) / Rational'(I3/I4);   

   R := Integer'(I1/I2) / (I3/I4);   
   R := (I1/I2) / Integer'(I3/I4);
   R := Integer'(I1/I2) / Integer'(I3/I4);
 
> Solution (a) would make it possible to break existing code by adding
> innocently-looking functions.

Possible in theory, but unusual in practice.
> 
> Solution (b) is much, much worse. It is not only harder to read
> potentially ambiguous code because you need to know more rules to
> interpret it (and disambiguating rules tend to contain arbitraryness which
> makes remembering the correct rules even harder).

Agreed.  C++ is a disaster in this respect, especially in conjunction
with the implicit conversions introduced by conversion constructors.

> It also introduces subtle changes in semantics - when a new function like
> (3) is introduced, routine calls all over the rest of the system might
> dispatch to the new function, and without an obvious hint to the
> programmer. (You can't even use a string-search tool to find all affected
> calls, because the "+" function is heavily overloaded.)

Again, this has nothing to do with dispatching, which is run-time
selection of a particular subprogram version, based on the value of an
operand's tag in a context where that value cannot be known at compile
time.
 
> I'd like to hear wether this is a real problem in Ada or wether I'm seeing
> ghosts here.

Well, let's just say that it was appropriate that you posted your
message on October 31. ;-)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Eiffel and Java

[Ell]

Ranjan Bagchi (ranjan.bagchi@pobox.com) wrote:
: Chris wrote:
: > 
: > The point with Java is that it's nearly C++.
: > 
: > So, even if it's not the best language, the C++ community would choose it
: > 
: > That's enough to make it a standard !
: > 
: > Chris
 
: Note:  Smalltalk bias.
: 
: I'd think that this kind standard would tend to produce a lot of Java 
: code which is just "C++ written in Java".  That is C++ code with 
: whatever syntactic tweaking is needed to get it pass the compiler.  

And there are large amounts of fully object-oriented C++, just as there
are other forms of C++ code.  I.e. there is much C++ code which models in
an OO way, and which uses OO design techniques to reduce dependencies.
 
: This is similar to what has happened in the C++ community where the joke 
: was that there were only 5 real C++ programmers and everyone else was 
: just coding C.  There wasn't enough incentive to use the kind of C++ 
: idioms that Coplien and Myers write about in their books.
: 
: That's what's really neat about languages like Smalltalk where
: the language forces programmers to start thinking in Smalltalk's object 
: model and produce Smalltalk written in Smalltalk.

Isn't it possible for someone to write a Smalltalk program with bad design
decompostion from an OO perspective? 

Elliott

Re: Eiffel and Java

[traymond]

In <55e611$abq@news3.digex.net>, ell@access4.digex.net (Ell) writes:
>Ranjan Bagchi (ranjan.bagchi@pobox.com) wrote:

>: That's what's really neat about languages like Smalltalk where
>: the language forces programmers to start thinking in Smalltalk's object 
>: model and produce Smalltalk written in Smalltalk.
>
>Isn't it possible for someone to write a Smalltalk program with bad design
>decompostion from an OO perspective? 
>
>Elliott

Sure it's possible to write poor programs in any language.
However, it is harder to write non-oo code in Smalltalk than
C++.  Furthermore, because most Smalltalk environments have
large libraries that include source code, novice Smalltalk
programmers have easy access to good examples to assist in
their learning.


===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
19 Tilley Ave.                  VW and Envy 
Newport, RI  02840
(401) 846-6573      traymond@craftedsmalltalk.com
http://www.craftedsmalltalk.com
===========================================================

Re: Eiffel and Java

[Jon S Anthony]

In article <6Jw2qT9k3RB@herold.franken.de> jhd@herold.franken.de (Joachim Durchholz) writes:

> jsa@alexandria wrote 30.10.96:
> 
> > 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:
> 
> Actually, I see this as a *flaw* in Ada.
> 
> Yes, it allows one to play some neat and useful tricks with dispatching.
> 
> But it also allows totally ambiguous expressions. Example:
> Let's have fictitious types INT and LONGINT, with the obvious operator  
> definitions
>   INT + INT -> INT               (1)
>   INT + INT -> LONGINT           (2)
>   INT + LONGINT -> LONGINT       (3)
>   LONGINT + INT -> LONGINT       (4)
>   LONGINT + LONGINT -> LONGINT   (5)
> However, this is ambiguous in an expression like
>   (INT + INT) + LONGINT

No problem.  Because this is an operation of specific types and so is
statically checked and bound at compile time.  And here, give that all
the operations would be visible, the Ada compiler would catch this and
flag it as an ambigous expression (note it is _statically_ flagged).

Note that this has absolutely nothing to do with dispatching on a
result and hence is basically irrelevant to the context.  It is simply
ordinary normal overloading resolution.


> because there are two possible interpretations:
>   (INT +(1) INT) +(3) LONGINT
> and
>   (INT +(2) INT) +(4) LONGINT

Which will be called to your attention.


> I'm not sure how Ada handles such cases. Solution (a) might be a compiler  
> error as soon as the compiler detects potentially ambiguous operator (or  
> function) declarations, solution (b) might be disambiguating rules.

Modified Solution (a): Only if at the point of _USE_ the expression is
not resolvable is there a problem and it will be flagged at compile
time.  The definitions may well be in totally separate name spaces,
defined at different times, etc. and so should not be flagged as
ambiguous (the signatures are all quite distinct).


> Solution (a) would make it possible to break existing code by adding  
> innocently-looking functions.

Only if you play fast and loose with polluting your name space.  Which
is why the use of "use" is so frowned upon in many circles.


> Solution (b) is much, much worse. It is not only harder to read  

Solution (b) is not relevant, :-)

> I'd like to hear wether this is a real problem in Ada or wether I'm seeing  
> ghosts here.

You're seeing ghosts.  The problem you mention with (a) _is_ possible
if you write (what would universally be considered in Ada practice)
horrible code.  But even there, it would only happen if you were to
1) Go back and change existing code (it won't happen if you are
   _extending_ the code).

AND

2) Willy nilly pollute the name space of the code.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Eiffel and Java

[Jon S Anthony]

In article <6Jw2q2$-3RB@herold.franken.de> jhd@herold.franken.de (Joachim Durchholz) writes:

> jsa@alexandria wrote 30.10.96:
> 
> > > 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 saw the original Ada definition, and the language struck me as  
> interesting and elegant in some places, but somewhat complicated and  
> convoluted in others.

You mean Ada83?

> From that standpoint, I'd really like to see such a short list of
> how Ada 95 is intended to work.

Not all of Ada (I'm not that crazy!), that wasn't the context - just
the OO part (that is what the concepts in "All the concepts" refers
to...).  I can send you such a list or post it here if you wish.


> > > 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.
> 
> Not really. A single way to do things can be a great advantage, if that  
> single way is well done. Just compare the type systems of some RAD  

Sure.  Sometimes.  As I pointed out once before, being a mathematician
(a pure one at that) I like this "pure" aspect in theory.  It just
doesn't apply very well as software is not mathematics.  It's a lot
closer to engineering (and can't even seem to adhere to the principles
there...)


> > 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).
> 
> I don't quite follow you here. MI is complicated and a semantic mess in  
> C++. It imposes efficiency problems in most languages. None of this  

I am talking formally.  Not as an expediency in hacking out software.
So, here *I* am playing the theoretical "purist" role.  Classification
systems are _one_ way to organize knowledge and MI gums up (breaks)
formal treatments of them.  As an implementation strategy for code
reuse it can have its place - and Eiffel (and Sather) are about the
only things which present an "acceptable" version.


> I agree basing a program's structure on classes only is somewhat dogmatic.  
> Clusters retrofit some structure on the Eiffel classes, but I don't see  
> anything fundamentally wrong with them.

There isn't anything wrong with them.  People shoe-horning
inappropriate cases into them are the problem.


> > Yes, this is "simpler", but it is also inaccurate.
> 
> Please clarify. "Inaccurate" in what way?

There are many sorts of models which are not classification schemes.
If all you have to represent these is a classification scheme you are
going to wind up pounding square pegs in round holes (at best) or with
outright inaccuracies.  The former simply results in inefficiency of
design and probably the resulting artifact.  The latter just gives
wrong results.

I'm not sure where people have got it in there head that class based
inheritance schemes are the only representation (let alone the best) for
everything.


> > 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.
> 
> Hmm - in computer science, you usually define the essence of a thing by  
> describing what you can do with it :)

Hmmm, maybe that is a reason why I've never thought much of CS... :-)


> > dream up your own for that matter.  All this with just one simple
> > construct - not several with mushed together semantic confusions.
> 
> On the same grounds, one could say an Eiffel class is a simple and pure  
> construct, though it happens to be versatile. I think I see a tendency to  

You could.  But it isn't.  It has at least the semantics of modules
and types combined as well as providing for things like information
hiding.


> consider one's pet concepts as simple (seeing the underlying ideas), and  
> to consider the opponent's pet concepts as complicated and tricky (seeing  

I suppose.  By simple I mean (at the language level) has a single
semantic and which is orthogonal to other constructs so as to allow
side effect free combination with these other constructs.  A good set
of flexible "primitives".  This supports the direct creation of a more
diverse set of possible end constructs.  Of course, the price is you
don't have some of the more typical things as out of the box "single
units".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Eiffel and Java

[Fergus Henderson]

jsa@alexandria (Jon S Anthony) writes:

]shang@corp.mot.com (David L. Shang) writes:
]
]> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
]> > Suppose I have two existing library classes (perhaps supplied by different
]> > vendors) which have some commonality, but don't inherit from a common
]> > base class.  In Sather, one can simply create a new interface and
]> > declare these classes to be instances of this interface, without
]> > modifying the existing code.
]> > 
]> > (Is that possible in Java?)
]> 
]> No. Java supports only top-down class hierarchy construction
]> (from superclass to subclasses), but not bottom-up: from
]> subclasses to superclass.

Why not?  I would have thought that since Java has separate interface
inheritence already, it would not be difficult to provide this feature.

]But in general it is _trivial_ to do in Ada.

I'm skeptical.

]with Stacks;  -- Generic
]with Queues;  -- Generic
]generic
]    type Any_Obj is tagged private;
]package Stack_Or_Queue
]
]    package S is new Stacks(Any_Obj);
]    package Q is new Queues(Any_Obj);
]
]    type Any is access all Any_Obj'Class;
]    type Stack_Queue ( S : access S.Stack; Q : access Q.Queue ) is private;
]...
]procedure Push (Element : Any;  Onto : Stack_Queue);
]function  Pop  (SQ : Stack_Queue) return Any;
]...
]private
]    type Stack_Queue ...
]...
]end Stack_Or_Queue;

Can I use this stack_or_queue interface to access different
implementations of the stack type (e.g. using arrays or using
linked lists?)  How about priority_queues?
With the Sather version, anything that implements push and pop can be
declared to implement the stack_or_queue interface.  It looks like
your stack_or_queue interface has exactly two implementations and
can't be extended.  (And that's despite being much more verbose
and complicated than the Sather version.)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Eiffel and Java

[Darko BUDOR]

Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
: donh@syd.csa.com.au (Don Harrison) writes:
: 
: >What is the purpose of separating interface and implementation inheritance? 
: 
: Suppose I have two existing library classes (perhaps supplied by different
: vendors) which have some commonality, but don't inherit from a common
: base class.  In Sather, one can simply create a new interface and
: declare these classes to be instances of this interface, without
: modifying the existing code.
: 
: (Is that possible in Java?)

Yes, it is. Suppose you have 2 classes from different vendors, class A and
class B, with common methods void foo() and void bar(). You can declare an
interface for common methods:

public interface common {
	public void foo();
	public void bar();
}

Now declare 2 new classes:

public class MyA extends A implements common {
	/* need constructors */.
};

public class MyB extends B implements common {};

and use MyA and MyB instead of A and B.

-- 
Darko Budor -- budor@fly.cc.fer.hr; dbudor@diana.zems.fer.hr

All parts should go together without forcing.  You must remember that the
parts you are reassembling were disassembled by you.  Therefore, if you 
can't get them together again, there must be a reason.  By all means, do 
not use a hammer.			--IBM maintenance manual, 1925

Re: Eiffel and Java

[Fergus Henderson]

dbudor@zems.fer.hr (Darko BUDOR) writes:

]Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
]: Suppose I have two existing library classes (perhaps supplied by different
]: vendors) which have some commonality, but don't inherit from a common
]: base class.  In Sather, one can simply create a new interface and
]: declare these classes to be instances of this interface, without
]: modifying the existing code.
]: 
]: (Is that possible in Java?)
]
]Yes, it is.

If your code below is the only way of doing it, then I would say that
it *isn't* possible in Java.  The code below doesn't do the same
thing as the Sather code -- it has significant disadvantages.

]Suppose you have 2 classes from different vendors, class A and
]class B, with common methods void foo() and void bar(). You can declare an
]interface for common methods:
]
]public interface common {
]	public void foo();
]	public void bar();
]}

Fine so far...

]Now declare 2 new classes:
]
]public class MyA extends A implements common {
]	/* need constructors */.
]};

Disadvantage number one: you have to manually delegate all the constructors.
That is tedious and causes maintenance difficulties when someone later adds
new constructors for A.

]and use MyA and MyB instead of A and B.

Disadvantage number two: you can't use the new interface on the
original types.  This is *really* bad news.  It basically means is that
you can't use this method when interfacing with existing code that uses
A and B rather than MyA and MyB.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Eiffel and Java

[Jon S Anthony]

In article <55fduh$6nc@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:

> jsa@alexandria (Jon S Anthony) writes:
> 
> ]shang@corp.mot.com (David L. Shang) writes:
>...
> ]> 
> ]> No. Java supports only top-down class hierarchy construction
> ]> (from superclass to subclasses), but not bottom-up: from
> ]> subclasses to superclass.
> 
> Why not?  I would have thought that since Java has separate interface
> inheritence already, it would not be difficult to provide this feature.

David Shang wrote that.  And, actually, I would tend to agree with you.
So, why would Java have a problem here?


> ]But in general it is _trivial_ to do in Ada.
> 
> I'm skeptical.

:-).  Always a wise stance!  Clearly I waxed hyperbolic...


> ]with Stacks;  -- Generic
> ]with Queues;  -- Generic
> ]generic
> ]    type Any_Obj is tagged private;
> ]package Stack_Or_Queue
> ]
> ]    package S is new Stacks(Any_Obj);
> ]    package Q is new Queues(Any_Obj);
> ]
> ]    type Any is access all Any_Obj'Class;
> ]    type Stack_Queue ( S : access S.Stack; Q : access Q.Queue ) is private;
> ]...
> ]procedure Push (Element : Any;  Onto : Stack_Queue);
> ]function  Pop  (SQ : Stack_Queue) return Any;
> ]...
> ]private
> ]    type Stack_Queue ...
> ]...
> ]end Stack_Or_Queue;
> 
> Can I use this stack_or_queue interface to access different
> implementations of the stack type (e.g. using arrays or using
> linked lists?)

Yes.


> How about priority_queues?

You mean something like, how does this work if you keep extending the
queues?  That should be OK.  If you mean something like, I have a
_different_ priority_queue thingy here (not derived from queues) -
will it just fit in and work?  No, that will require going back and
futzing...


> With the Sather version, anything that implements push and pop can be
> declared to implement the stack_or_queue interface.

Good point.


> It looks like your stack_or_queue interface has exactly two
> implementations and can't be extended.  (And that's despite being
> much more verbose and complicated than the Sather version.)

It has exactly two sorts of _interfaces_ (despite being more verbose
and complicated).  You can have different implementations of these and
that should still work.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Eiffel and Java

[Matt Kennel]

Fergus Henderson (fjh@murlibobo.cs.mu.OZ.AU) wrote:
: Disadvantage number two: you can't use the new interface on the
: original types.  This is *really* bad news.  It basically means is that
: you can't use this method when interfacing with existing code that uses
: A and B rather than MyA and MyB.

This issue comes about when your library framework which you can't change
creates and returns new objects of type A and B.

: --
: Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
: WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
: PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 
  I would not, could not SAVE ON PHONE,    |==================================
  I would not, could not BUY YOUR LOAN,    |The US Government does not like
  I would not, could not MAKE MONEY FAST,  |spam either.  It is ILLEGAL!
  I would not, could not SEND NO CA$H,     |USC Title 47, section 227
  I would not, could not SEE YOUR SITE,    |p (b)(1)(C) www.law.cornell.edu/
  I would not, could not EAT VEG-I-MITE,   | /uscode/47/227.html
  I do *not* *like* GREEN CARDS AND SPAM!  |==================================
               M A D - I - A M!

Re: Eiffel and Java

[Matthias Ernst]

Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
: Suppose I have two existing library classes (perhaps supplied by different
: vendors) which have some commonality, but don't inherit from a common
: base class.  In Sather, one can simply create a new interface and
: declare these classes to be instances of this interface, without
: modifying the existing code.

We have seen examples how to do it in Sather, Transframe, Ada and Java(or
not). These are all languages where one explicitly has to annotate in the
definition of A or the one of B if A is to be subtype of B. There exist
however languages (Emerald, PolyToil, Quest (not even OO), others ?) with
structural subtyping which means that a type A automagically is subtype of a
type B if it has a conforming interface. This introduces the possibility of
'subtyping by chance' but on the other hand eliminates the problem described
above. If you want a supertype just declare it. The existing types will be
substitutable for it.

I wonder if anyone out there has experience with this form of type system.
Though it is easier to use, does one perhaps confuse more easily the type
hierachy ?

-- Matthias

Re: Eiffel and Java

[Darko BUDOR]

Fergus Henderson (fjh@murlibobo.cs.mu.OZ.AU) wrote:
: ]: (Is that possible in Java?)
: ]
: ]Yes, it is.
: 
: If your code below is the only way of doing it, then I would say that
: it *isn't* possible in Java.  The code below doesn't do the same
: thing as the Sather code -- it has significant disadvantages.

It doesn't do the same thing, but that is as close as you can get. 

: Disadvantage number one: you have to manually delegate all the constructors.
: That is tedious and causes maintenance difficulties when someone later adds
: new constructors for A.

So you will have to add one to MyA, if you want to use it. I see no problem
there.

: ]and use MyA and MyB instead of A and B.
: 
: Disadvantage number two: you can't use the new interface on the
: original types.  This is *really* bad news.  It basically means is that
: you can't use this method when interfacing with existing code that uses
: A and B rather than MyA and MyB.

That IS a bit of a problem, but it could be solved with copy constructors 
in derived classes, IMHO. 

-- 
Darko Budor -- budor@fly.cc.fer.hr; dbudor@diana.zems.fer.hr

All parts should go together without forcing.  You must remember that the
parts you are reassembling were disassembled by you.  Therefore, if you 
can't get them together again, there must be a reason.  By all means, do 
not use a hammer.			--IBM maintenance manual, 1925

Re: Eiffel and Java

[Joachim Durchholz]

ncohen@watson.ibm.com wrote 01.11.96:

> The issue you address above is overloading, i.e., the declaration of
> multiple subprograms with the same name, resolved at compile time based
> on the types of parameters and function results.

You are right here, I confused that.
Though I'd expect that similar problems exist for dispatching as well as  
for overloading. In both cases, it is necessary to decide which of several  
similar functions is the right one, overloading at compile time,  
dispatching (dynamic binding) at run-time.

> Well, let's just say that it was appropriate that you posted your
> message on October 31. ;-)

Is there anything special about Oct 31? It is called "Reformation Day"  
here in Germany (has to do with Luther and Protestants), but I'm not sure  
you mean that or something else...

Regards,
-Joachim

--
Looking for a new job. Resume available on request. WWW version of resume
available under http://www.franken.de/users/herold/jhd/resume/index.html

Re: Eiffel and Java

[James McKim]

In article <mheaney-ya023180000111962205520001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:
>In article <1996Oct31.201748.29073@merlin.hgc.edu>, jcm@hgc.edu (James
>McKim) wrote:
>
>>>>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 
>>
>>Whoa, about the simplest precondition I can think of is related to accessing
>>the top of a generic stack.
>>
>>class STACK[G]
>>...
>>  top : G is
>>  require
>>    not_empty: depth > 0
>>...
>>
>>How do you emulate this using types in Ada? 
>
>Perhaps I didn't make my original point clear.  The designers of Ada 95
>considered including some precondition/postcondition checking in the
>language (as Eiffel does), but opted not to because Ada's rich typing
>mechanisms already provide "some of" that.

Well, I've lost track of who said what. "some of" I'll buy, but I quarrel 
with either "equivalent of" (from the first line above) or "much of"
(from another poster in this thread) I quarrel with.


[... Nice example of a compass elided ...]

>
>That subtype constraints are a form of pre- and post-condition it what I
>was trying to say.  Please note that I like Eiffel and think its facilities
>for checking assertions, pre-, and post-conditions are way cool and yes, I
>really would like something like that in Ada.  Perhaps for the next
>revision of the language.

:-) FTR, Ada has some good stuff that Eiffel is currently missing, e.g.
threads.

>
>As for how to assert precondition that a stack be non-empty, I can already
>do that in Ada:
>
>generic
>   type T is private;
>package Bounded_Stacks is
>
>   type Stack (Size : Positive) is limited private;
>
>   function Top (S : Stack) return T;
>
>...
>
>private
>
>   type Item_Array is array (Positive range <>) of T;
>
>   type Stack (Size : Positive) is
>      record
>         Items : Item_Array (1 .. Size);
>         Top : Natural := 0;
>      end record;
>
>end;
>
>package body Stacks is
>
>   function Top (S : Stack) return T is
>   begin
>      return S.Items (S.Top);
>   end;
>...
>end;
>
>If the stack is empty, then S.Top = 0 and the call to function Top will
>(automatically) raise Constraint_Error, because the array index constraint
>was violated.
>
>Just like a precondition.
>
>If you don't like Constraint_Error, then put a handler for it in body of
>Top and raise the exception of your choice.
>

Well, "just like" is too strong I think.

1) As far as I can tell the precondition is not visible to clients without
your doing yet more work.

2) The error that is raised will not be a precondition error, it'll be
a constraint error as you note. I see you can fix this with a little
more work, but that extra work is what keeps it from being "just like"
a precondition check in Eiffel.

3) The exception will be raised in the the supplier, but the onus of precondition checks is on the client and that's where the exception would be 
raised in Eiffel.

4) Perhaps most importantly, if I change the implementation of the Stack
away from an ARRAY I'd have to do yet more work to make sure that an exception
is still generated at the appropriate time and with the appropriate message.
 
>--------------------------------------------------------------------
>Matthew Heaney
>Software Development Consultant
>mheaney@ni.net
>(818) 985-1271

Hope this helps,
-- Jim


-- 

*------------------------------------------------------------------------------*
Jim McKim  (860)-548-2458     Teachers affect eternity. They can never tell 
Internet:  jcm@hgc.edu        where their influence stops.

Re: Eiffel and Java

[Robert I. Eachus]

In article <55crp0$qn9@dscomsa.desy.de> mernst@x4u2.desy.de (Matthias Ernst) writes:

  > All languages that unify inheritance and subtyping enforce that
  > once you inherit from a class you build a subtype. There are
  > several examples (mostly with binary methods and the type Self,
  > SAME, like Current or whatever) that show that it may be the
  > implementation you are interested in but you can't guarantee
  > subtype relationship.

  > class Comparable
  > is
  >   "<="(other: Self): Bool is abstract;
  >   ">="(other: Self): Bool is other <= self end;
  >   ">"(other: Self): Bool is ~(self <= other) end;
  >   "<"(other: Self): Bool is other > self end;
  > end;...

    I think I understand what you want here, but it works fine in Ada 95:

  package Compare is
    type Comparable is tagged private;
    function "<=" (L,R: Comparable) return Boolean is abstract;
    function ">=" (L,R: Comparable) return Boolean;
    function ">" (L,R: Comparable) return Boolean;
    function "<" (L,R: Comparable) return Boolean;
  private
    type Comparable is null record;
  end Compare;

  package body Compare is

    function ">=" (L,R: Comparable) return Boolean is 
    begin return R <= L; end ">=";

    function ">" (L,R: Comparable) return Boolean is
    begin return not (L <= R); end ">";

    function "<" (L,R: Comparable) return Boolean;
    begin return not (R <= L); end "<";

  end Compare;

    For types derived from Comparable, you only need to define the one
inequality operation.  The other possibility is that you want a
generic template.  That works in Ada 95 as well:

  generic
    type Comparable is tagged private;
    with function "<=" (L,R: Comparable) return Boolean is <>;
  package Compare is
    function ">=" (L,R: Comparable) return Boolean;
    function ">" (L,R: Comparable) return Boolean;
    function "<" (L,R: Comparable) return Boolean;
  end Compare;

  package body Compare is -- (same as above)

    I went through all this because it is one of the cases where the
symmetric Ada notation does have technical advantages.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Eiffel and Java

[David L. Shang]

In article <55ditr$pnh@gaia.ns.utk.edu> mbk@caffeine.engr.utk.edu (Matt Kennel)  
writes:
> David L. Shang (shang@corp.mot.com) wrote:
> : But Sather's superclass construction is limited to non-parametrerized
> : classes only.
> 
> This isn't true, at least in 1.1.  The following compiles and executes. 
> 
> -------------------------------------------------------
> -- demonstrate abstract superclass over a parameterized type. 
> -------------------------------------------------------
> abstract class $OVER{T} > $P{T} is
>    feature1(arg:T);
> end;
> 
> abstract class $P{T} is
>   feature1(arg:T);
>   feature2(arg:T);
> end; 
> 
> class CONCRETE{T} < $OVER{T} is
>    feature1(arg:T) is #OUT + "In feature\n"; end;
>    create:SAME is return new; end; 
> end;    
> 
>    
> class MAIN is
> 	main is
> 	  #OUT + "Hello World.\n";
> 	  
> 	  ob :$OVER{INT} := #CONCRETE{INT}; 
> 	  ob.feature1(42);
> 
>         end;
> end;
> 

Try the following, if Sather's compiler does not complain, then,
Sather's generic class is equivalent to Transframe's:

class MAIN is
	main is
	  #OUT + "Hello World.\n";
	  
	  ob :$OVER;
	  if (some_input_condition) ob := #CONCRETE{INT}; 
	  else ob = #P(STRING);
	  
	  // at this point, we don't know the exact element type of ob
	  // type assurance must be used
	  assume (typeof(ob).ElementType is INT) ob.feature1(42);

        end;


> : Transframe provides a more powerful superclass construction that 
> : can support parameterized classes.
> 
> : Suppose we have two existing classes
> : ....
> 
> I believe that Sather could express the same concept. 
> 

The concept of generic class in Sather is different than Transframe's.

David Shang

Re: Eiffel and Java

[David L. Shang]

In article <JSA.96Nov1182422@alexandria> jsa@alexandria (Jon S Anthony) writes:
> In article <1996Oct31.162218.8386@schbbs.mot.com> shang@corp.mot.com (David  
L. Shang) writes:
> 
> > No. Java supports only top-down class hierarchy construction
> > (from superclass to subclasses), but not bottom-up: from
> > subclasses to superclass.
> 
> But in general it is _trivial_ to do in Ada.  Note that "inheritance"
> aspects need not (and typically will not) even enter into the
> "equation" since the functionality is provided by separating the
> "module" aspect of class from the "type" aspect and allowing the
> module aspect to have separate spec. and impl.
> 

Don't you think that the Ada's code is rather complicated and
involves too many concepts to describe things clearly?

Transframe's version:

        use Stack, Queue;
 	class StackOrQueue #(MemberType: type of any)
 			is super Stack, Queue
 	{
 		function push(MemberType);
 		function pop:MemberType;
 	}

	use StackOrQueue;
	function MyTestCode()
	{ 
 	    x: StackOrQueue;
 	    if (some_condition) x = Stack#(T1)(); else x:=Queue#(T2)();
 	    y: any = GetObject();
 	    assume (y is x#.MemberType) x.push(y); otherwise do_nothing();
	    ....
	}
 
Your Ada's Version:

	with Stacks;  -- Generic
	with Queues;  -- Generic
	generic
	     type Any_Obj is tagged private;
	package Stack_Or_Queue
	 
	     package S is new Stacks(Any_Obj);
	     package Q is new Queues(Any_Obj);
	 
	     type Any is access all Any_Obj'Class;
	     type Stack_Queue ( S : access S.Stack; Q : access Q.Queue )
			is private;
	
	     procedure Push (Element : Any;  Onto : Stack_Queue);
	     function  Pop  (SQ : Stack_Queue) return Any;

	     private
	         type Stack_Queue ...
	
	end Stack_Or_Queue;
	 
	with Stack_Or_Queue;
	    package SQ_T1 is new Stack_Or_Queue(T1);
	         package ST1 renames SQ_T1.S;
	    package SQ_T2 is new Stack_Or_Queue(T2);
	         package QT2 renames SQ_T2.Q;
	    S : ST1;
	    Q : QT2;
	    if (some condition) then
	         declare
	             X : SQ_T1(S, null);  -- X is a stack of T1s
	             Y : SQ_T1.Any := Get_Object;
	         begin
	             push(Y, Onto => X);
	         end;
	     else
	         declare
	             X : SQ_T2(null, Q);  -- X is a queue of T2s
	             Y : SQ_T2.Any := Get_Object;
	         begin
	             ...
	     end if;

And the above Ada's code is still not equivalent to Transframe's
code. There is no polymophism on the generic class StackOrQueue
in Ada's code: the variable "X" is not polymorphic, and is only
valid within a local scope. What happen if I want a function to
return the value of "X" for other people to use? For example:

	use StackOrQueue;
	function CreateStackOrQueue(some_condition: bool): StackOrQueue
	{ 
 	    x: StackOrQueue;
 	    if (some_condition) x := Stack#(T1)(); else x:=Queue#(T2)();
 	    y: any= GetObject();
	    while (y) 
 	    {
		assume (y is x#.MemberType) x.push(y);
		otherwise do_nothing();
		y:= GetObject();
	    }
	    return x;
	}


David Shang

Re: Eiffel and Java

[Richard A. O'Keefe]

Sacha@easynet.fr (Vincent WEBER) writes:
>  By the way, one more thing : I just had a look at ADA 95 and it's "OO" model. 
>Even if I admit it is powerful, I think it's very heavy.

This puzzles me considerably.
The Ada 95 OO model is essentially the same as the C++ model,
restricted to single inheritance.
Unlike OOP in Smalltalk, Simula 67, and the proposed OOP extensions
to Pascal, objects need not be referred to via pointers.
The syntax is very lightweight as well.

>However, one thing interested me : Ada 
>fanatics claim that the dot notation break the symetry of natural operation, 
>and that Ada's model of dynamic bindings in all the parameters of a procedure 
>is better (that is, writing for instance Add(VectorA, VectorB) instead of 
>VectorA.Plus(VectorB). I don't know what to think about this controversy. Any 
>idea ?

(a) Where did you find any Ada fanatics?  People are usually drawn to
    Ada because they are aware of their own fallibility.

(b) It baffles me that this late in the millenium, some people think that
    whether you write
	f(x)
    or  x.f
    is something important.  In the Pop family of languages, the two
    notations have been identical for 3 decades or more.  There was a
    paper from Xerox on uniform reference which probably needs republishing.

(c) What _does_ matter is semantics, and here C++ runs into a problem that
    Ada 95 avoids:  an expresssion "a < b" could be interpreted _either_
    as a call to a function operator <(a, b) _or_ as a method call
    a.operator <(b).  This can interact with inheritance in surprising ways.

>  Thanks to anyone that would help to elect my favourite language :) Currently, 
>I believe that Eiffel is the best OOPL, even if the reality of industry force 
>me to live the nightmare of C++ everyday :)

It sounds as though you have already made your choice.
And that without looking at CLOS, or Sather, or Self, or Cecil, or ...

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Eiffel and Java

[Robert I. Eachus]

In article <JSA.96Nov2201641@alexandria> jsa@alexandria (Jon S Anthony) writes:

  > You mean something like, how does this work if you keep extending
  > the queues?  That should be OK.  If you mean something like, I
  > have a _different_ priority_queue thingy here (not derived from
  > queues) - will it just fit in and work?  No, that will require
  > going back and futzing...

   This looks like a case where you want interface inheritance, so
implement interface inheritance:

   generic
     type Stack_or_Queue is limited tagged private;
     type Element is tagged private;
     with function Pop(SQ: in Stack_or_Queue) return Element'Class is <>;
     with procedure Push(E: in Element; Onto: in out Stack_or_Queue) is <>;
     with function Is_Empty(SQ: in Stack_or_Queue) return Boolean is <>;
     -- etc.
   -- your procedure, function, or package goes here.

   For any Stack, Queue, Deque, etc., which matches the interface you
can instantiate your generic.  You can even figure out a meaningful
definition of Is_Empty for a queue connected to a pipe if that is what
you have.  (For example, delay until the other end of the pipe is
closed and return false, or until another element is put into the pipe
and return true.)


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Eiffel and Java

[Don Harrison]

James McKim writes:

:>eg. class SET_OPS
:>      ...
:>      union (a, b: SET): SET is ...
:>      intersection (a, b: SET): SET is ...
:>      ...
:>    end

:In an article in the 10/94 issue of JOOP, Richie Bielak and I argued that
:such features should really be creation routines in class SET.

Good idea. (This article is titled "Let there be objects"). This looks
like it would apply to most situations including creation types different
from the parameters. It also preserves the philosophy of side-effect-free 
functions which my example violated. :(

:IMHO, the dot notation and the desire for symmetry are almost orthogonal
:issues. For better or for worse many library classes for languages that support
:the dot notation have chosen to design intrinsically symmetric operations in
:an asymmetric way, but that is not the only way.

Agree. Good designs should preserve symmetry.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Eiffel and Java

[Matt Kennel]

David L. Shang (shang@corp.mot.com) wrote:
: In article <55ditr$pnh@gaia.ns.utk.edu> mbk@caffeine.engr.utk.edu (Matt Kennel)  
: writes:
: > David L. Shang (shang@corp.mot.com) wrote:
: > : But Sather's superclass construction is limited to non-parametrerized
: > : classes only.
: > 
: > This isn't true, at least in 1.1.  The following compiles and executes. 
: > 
: > -------------------------------------------------------
: > -- demonstrate abstract superclass over a parameterized type. 
: > -------------------------------------------------------
: > abstract class $OVER{T} > $P{T} is
: >    feature1(arg:T);
: > end;
: > 
: > abstract class $P{T} is
: >   feature1(arg:T);
: >   feature2(arg:T);
: > end; 
: > 
: > class CONCRETE{T} < $OVER{T} is
: >    feature1(arg:T) is #OUT + "In feature\n"; end;
: >    create:SAME is return new; end; 
: > end;    
: > 
: >    
: > class MAIN is
: > 	main is
: > 	  #OUT + "Hello World.\n";
: > 	  
: > 	  ob :$OVER{INT} := #CONCRETE{INT}; 
: > 	  ob.feature1(42);
: > 
: >         end;
: > end;
: > 

: Try the following, if Sather's compiler does not complain, then,
: Sather's generic class is equivalent to Transframe's:

: class MAIN is
: 	main is
: 	  #OUT + "Hello World.\n";
: 	  
: 	  ob :$OVER;
: 	  if (some_input_condition) ob := #CONCRETE{INT}; 
: 	  else ob = #P(STRING);
: 	  
: 	  // at this point, we don't know the exact element type of ob
: 	  // type assurance must be used
: 	  assume (typeof(ob).ElementType is INT) ob.feature1(42);

:         end;

I don't think the generic class concept is the same, but the following
appears to do what you desire.  The main difference is that in Sather
$TYPE{T} and $TYPE are wholly unrelated _a priori_.  $TYPE is not a superytpe
of $TYPE{T} unless explicitly declared that way, as in this example. 


---------------------
abstract class $OVER is
   -- over everything
end; 

abstract class $OVER{T} < $OVER > $P{T}  is
   feature1(arg:T);
end;

abstract class $P{T} is
  feature1(arg:T);
  feature2(arg:T);
end; 

class CONCRETE{T} < $OVER{T} is
   feature1(arg:T) is #OUT + "In feature\n"; end;
   create:SAME is return new; end; 
end;    

   
class MAIN is
   main(args:ARRAY{STR}) is
      #OUT + "Hello World.\n";
	  
      ob :$OVER;
      if args[1] = "int" then
	 #OUT + "Creating int\n";
	 ob := #CONCRETE{INT}; 
      else
	 ob := #CONCRETE{STR};
      end;
      
      typecase ob
      when $OVER{INT} then ob.feature1(42);
      else #OUT + "No matching typecase\n";
      end;
   end;
end;

-------
(~/sather1/hello) caffeine.engr.utk.edu > a.out int
Hello World.
Creating int
In feature
(~/sather1/hello) caffeine.engr.utk.edu > a.out other
Hello World.
No matching typecase
(~/sather1/hello) caffeine.engr.utk.edu >
-------


: > : Transframe provides a more powerful superclass construction that 
: > : can support parameterized classes.
: > 
: > : Suppose we have two existing classes
: > : ....
: > 
: > I believe that Sather could express the same concept. 
: > 

: The concept of generic class in Sather is different than Transframe's.

: David Shang

--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 
  I would not, could not SAVE ON PHONE,    |==================================
  I would not, could not BUY YOUR LOAN,    |The US Government does not like
  I would not, could not MAKE MONEY FAST,  |spam either.  It is ILLEGAL!
  I would not, could not SEND NO CA$H,     |USC Title 47, section 227
  I would not, could not SEE YOUR SITE,    |p (b)(1)(C) www.law.cornell.edu/
  I would not, could not EAT VEG-I-MITE,   | /uscode/47/227.html
  I do *not* *like* GREEN CARDS AND SPAM!  |==================================
               M A D - I - A M!

Re: Eiffel and Java

[Norman H. Cohen]

Joachim Durchholz wrote:

> Though I'd expect that similar problems exist for dispatching as well as
> for overloading. In both cases, it is necessary to decide which of several
> similar functions is the right one, overloading at compile time,
> dispatching (dynamic binding) at run-time.

But this choice is straightforward in the case of dispatching:  You
dispatch to the version for the type indicated by the tags of the
controlling parameters (or the controlling result).  If there is more
than one controlling parameter and the tags do not match, it is a
run-time error, raising an exception.

The only potential bit of ambiguity is in deciding whether a "tag
indeterminate" call--a call on a function that has a controlling result
and no controlling parameters except perhaps other tag indeterminate
calls--is dispatching.  The rule is that a tag-indeterminate call is not
a dispatching call unless it has to be.  A tag-indeterminate call has to
be a dispatching call if it is a parameter in some surrounding call that
has to be dispatching (e.g. because the surrounding call has a classwide
controlling parameter).  Here is an example:

   package P is
      type T is tagged ...;
      type CWP is access all T'Class;
      procedure S (X1, X2: in T);
      function F1 (X: T) return T;
      function F2 (X: Integer) return T;
   end P;

   A : CWP;
   B : T;

(A call on F2 is always tag-indeterminate.  A call on F1 is
tag-indeterminate if and only if its parameter is tag indeterminate, as
in F1(F2(0)) or in the outermost call of F1(F1(F2(0))).)

The call 
   S( F1(F2(0)), F2(1) );
is not dispatching.  Each call on F2, and the call on F1, return a value
of type T.  The call on S has two parameters of type T, causing the
version of S declared in P to be invoked.  The call
   S( F1(F2(0)), A.all);
IS dispatching, because the second parameter to S, A.all, is classwide. 
That means that the call on F1 must dispatch to the version of F1 for
the type indicated by the tag value A'Tag.  That, in turn, means that
the call on F2 must be dispatch to the version of F2 for that type.  The
rules in the RM are hard to understand, but the bottom line is that
dispatching occurs only in calls where there is data whose tag is not
determinable at compile time (looking at a single statement in
isolation).
 
> > Well, let's just say that it was appropriate that you posted your
> > message on October 31. ;-)
> 
> Is there anything special about Oct 31? It is called "Reformation Day"
> here in Germany (has to do with Luther and Protestants), but I'm not sure
> you mean that or something else...

You had asked whether you were "seeing ghosts".  October 31 is Halloween
(a variation on "All Hollows' Eve", i.e., the evening before All Saints
Day).  In the United States (I had thought this was a European tradition
too, and I am surprised to learn otherwise) it  has become associated
with ghosts, goblins, witches, and so forth (as well as with
institutionalized extortion by children who threaten to vandalize the
property of those who do not offer candy in return for protection).
 
-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Eiffel and Java

[Jon S Anthony]

In article <1996Nov4.142715.5411@schbbs.mot.com> shang@corp.mot.com (David L. Shang) writes:

> In article <JSA.96Nov1182422@alexandria> jsa@alexandria (Jon S Anthony) writes:
> > But in general it is _trivial_ to do in Ada.  Note that "inheritance"
> > aspects need not (and typically will not) even enter into the
> > "equation" since the functionality is provided by separating the
> > "module" aspect of class from the "type" aspect and allowing the
> > module aspect to have separate spec. and impl.
> > 
> 
> Don't you think that the Ada's code is rather complicated and
> involves too many concepts to describe things clearly?

The "solution" I gave is indeed just plain not the right one.  As
Robert Eachus pointed out, this is interface inheritance (with the
ability to have multipe impls of the interface(s)) and the way this
should be handled here is with generic formal packages.  I suppose I
should write up that solution and see how well it goes (in terms of
"verbosity and complex").

> 	with Stack_Or_Queue;
> 	    package SQ_T1 is new Stack_Or_Queue(T1);
> 	         package ST1 renames SQ_T1.S;
> 	    package SQ_T2 is new Stack_Or_Queue(T2);
> 	         package QT2 renames SQ_T2.Q;
> 	    S : ST1;
> 	    Q : QT2;
> 	    if (some condition) then
> 	         declare
> 	             X : SQ_T1(S, null);  -- X is a stack of T1s
> 	             Y : SQ_T1.Any := Get_Object;
> 	         begin
> 	             push(Y, Onto => X);
> 	         end;
> 	     else
> 	         declare
> 	             X : SQ_T2(null, Q);  -- X is a queue of T2s
> 	             Y : SQ_T2.Any := Get_Object;
> 	         begin
> 	             ...
> 	     end if;
> 
> And the above Ada's code is still not equivalent to Transframe's
> code. There is no polymophism on the generic class StackOrQueue

Actually, there is - but wrt to implementations.


> in Ada's code: the variable "X" is not polymorphic, and is only

It is on the various possible implementations of Qs & Ss, but not
otherwise.


> [X..] is only valid within a local scope. What happen if I want a
> function to return the value of "X" for other people to use? For
> example:

Right.


> 	use StackOrQueue;
> 	function CreateStackOrQueue(some_condition: bool): StackOrQueue
> 	{ 
>  	    x: StackOrQueue;
>  	    if (some_condition) x := Stack#(T1)(); else x:=Queue#(T2)();
>  	    y: any= GetObject();
> 	    while (y) 
>  	    {
> 		assume (y is x#.MemberType) x.push(y);
> 		otherwise do_nothing();
> 		y:= GetObject();
> 	    }
> 	    return x;
> 	}

Actually, this is not a problem in the above "solution".  You can certainly
return X from either scope (assuming a function context).

I will see how this fits with the "correct" sort of solution using
package parameters.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Eiffel and Java

[Jon S Anthony]

In article <EACHUS.96Nov4184435@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:

> In article <JSA.96Nov2201641@alexandria> jsa@alexandria (Jon S Anthony) writes:
> 
>   > You mean something like, how does this work if you keep extending
>   > the queues?  That should be OK.  If you mean something like, I
>   > have a _different_ priority_queue thingy here (not derived from
>   > queues) - will it just fit in and work?  No, that will require
>   > going back and futzing...
> 
>    This looks like a case where you want interface inheritance, so
> implement interface inheritance:
> 
>    generic
>      type Stack_or_Queue is limited tagged private;
>      type Element is tagged private;
>      with function Pop(SQ: in Stack_or_Queue) return Element'Class is <>;
>      with procedure Push(E: in Element; Onto: in out Stack_or_Queue) is <>;
>      with function Is_Empty(SQ: in Stack_or_Queue) return Boolean is <>;
>      -- etc.
>    -- your procedure, function, or package goes here.
> 
>    For any Stack, Queue, Deque, etc., which matches the interface you
> can instantiate your generic.  You can even figure out a meaningful
> definition of Is_Empty for a queue connected to a pipe if that is what
> you have.  (For example, delay until the other end of the pipe is
> closed and return false, or until another element is put into the pipe
> and return true.)

Right.  Actually, what occured to me after I wrote that was that this
sort of example should be dealt with by means of generic formal
package parameters.  After all, defining this sort of "generic"
signature is one of the very things that they were defined for...

I suppose (since I've gone this far along) that I should write up the
example using this technique.  I am pretty sure it will be about
exactly what one wants in this sort of case.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Eiffel and Java

[David L. Shang]

In article <55nvo4$mgk@gaia.ns.utk.edu> mbk@caffeine.engr.utk.edu (Matt Kennel)  
writes:
> 
> I don't think the generic class concept is the same, but the following
> appears to do what you desire.  The main difference is that in Sather
> $TYPE{T} and $TYPE are wholly unrelated _a priori_.  $TYPE is not a superytpe
> of $TYPE{T} unless explicitly declared that way, as in this example. 
> 

Correct. That's the major difference. Making $TYPE{T} be subtype of
$TYPE without explicit declaration will simplify the type system
and avoid redundant class hierarchy.

Besides, in Sather code,
     
>      typecase ob
>       when $OVER{INT} then ob.feature1(42);
>       else #OUT + "No matching typecase\n";
>       end;

you have to know the exact type of "ob" before you can call
"feature1".

In Transframe, what you want to assure is just the element type
to be "int". You are not necessary to know the enclosing type.

David Shang

Re: Eiffel and Java

[Marcos F. F. de Macedo]

Jon S Anthony wrote:

> Right.  As was pointed out back in that old thread, to get at the
> "separate" spec/impl aspects in Eiffel you would use an "abstract
> class" technique.  This doesn't quite work, but it is at least the
> proper analogue.

The spec/impl is to separate the way that clients see the class
(interface) from actual code/structure. This is done in Eiffel by the
short tool. The short tool generates the interface to an eiffel class
with more spec. than is done in Ada.

There is no need to write the interface if it could be stracted from the
source code. I should know that Ada was based on Modula-2 that used this
way of separating. Oberon, the sucessor of Modula-2, uses automatic
interface generating tool.

Marcos Macedo
Brazil

Re: Eiffel and Java

[Marcos F. F. de Macedo]

Fergus Henderson wrote:
> 
> donh@syd.csa.com.au (Don Harrison) writes:
> 
> >What is the purpose of separating interface and implementation inheritance?
> 
> Suppose I have two existing library classes (perhaps supplied by different
> vendors) which have some commonality, but don't inherit from a common
> base class.  In Sather, one can simply create a new interface and
> declare these classes to be instances of this interface, without
> modifying the existing code.
> 
> (Is that possible in Java?)
This kind of interface/implementation in Sather is diferent of the usual
concept. This is subtype/subclass independence. That is a good thing in
Sather that I have not yet thinked of the exact consequences.

Interfaces in Java have nothing to do with this concepts. Interface in
Java is an implementation restriction (not a conceptual one) to avoid
multiple-inheritance and work yet work with static typing. Interface is
java is just a deferred class with just deferred routines. Nothing more,
nothing less.

Marcos F. F. de Macedo
marcosm@sede.unijui.tche.br
UNIJUI - BRAZIL

Re: Eiffel and Java

[Ian Joyner]

For those following this thread, the C++ Critique has been updated to 
include comparisons with Eiffel and Java. You might find this of
some relevance. You can get the critique from the following URLs:

Browser addresses:

ftp://ftp.brown.edu/pub/c++/C++-Critique-3ed.PS      -- U.S. East
http://www.math.tau.ac.il/~laden/Oberon/bib-full.html#LanguageComparisons 
-- Europe
ftp://ftp.inria.fr/doc/lang/cpp.crit.ps.gz           -- France/Europe
http://www.lirmm.fr/~w3arc/fr/groupe-de-travail/cpp/cpp.crit.ps.gz  --
France/Europe
http://www.csd.uu.se/~alexb/study/cppv3.ps.gz        -- Europe
http://www.csd.uu.se/~alexb/study/cppv3.ps.Z         -- Europe
http://www.neurop2.ruhr-uni-bochum.de/personal/cozzi/sather.html   --
Germany/Europe
ftp://ftp.neurop2.ruhr-uni-bochum.de/pub/sather/papers/cppv3.ps.gz --
Germany/Europe
http://www.hsv.tis.net/~rew/doc/C++-Critique-3ed.PS.gz  -- U.S.
http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html -- Australasia

ftp details:

U.S East Brown University:

      Machine:       ftp.brown.edu
      Directory:     /pub/c++
      File:          C++-Critique-3ed.PS
      Browser:   ftp://ftp.brown.edu/pub/c++/C++-Critique-3ed.PS

U.S West Indiana University:     

      Hours:         AFTER 6pm Eastern US Please
      Machine:       moose.cs.indiana.edu
      IP #           129.79.254.191
      Directory:     pub
      GZIP:        ftp://ftp.cs.indiana.edu/pub/cpp.crit/cppv3.ps.gz
      Compressed:  ftp://ftp.cs.indiana.edu/pub/cpp.crit/cppv3.ps.Z

France/Europe IRISA/CNRS:

      Machine:       irisa.irisa.fr
      IP #           131.254.254.2
      Directory:     pub/c++_critique
      GZIPPed:   cppv3.ps.gs   (456K)
      Compressed cppv3.ps.Z  (535K)
      Browser:   
ftp://ftp.irisa.fr/pub/c++_critique/cppv3.ps.gs          -- GZIPped 
456K
      Browser:   
ftp://ftp.irisa.fr/pub/c++_critique/cppv3.ps.Z          --  Unix
compressed  535K

Re: Eiffel and Java

[David L. Shang]

In article <328592FC.64F26D66@sede.unijui.tche.br> "Marcos F. F. de Macedo"  
<marcosm@sede.unijui.tche.br> writes:
> This kind of interface/implementation in Sather is diferent of the usual
> concept. This is subtype/subclass independence. That is a good thing in
> Sather that I have not yet thinked of the exact consequences.
> 
> Interfaces in Java have nothing to do with this concepts. Interface in
> Java is an implementation restriction (not a conceptual one) to avoid
> multiple-inheritance and work yet work with static typing. Interface is
> java is just a deferred class with just deferred routines. Nothing more,
> nothing less.
> 

Separation of the interface from implementation is a good thing.
It is required by the practical software engineering needs to reduce
the dependency among software components. 

But separation subtype from subclass is not. It is not required for
any practical reason, rather, a patch to the imperfect supertype
specification.

In Sather, implementation classes are not always subtype of the
parent class. They merely reuse the code (inherite the implementation)
defined in their parent, but not necessarily be subtype of it.
Without subtyping, the interface provided in the parent cannot
serve as a polymorphic interface for all the implementations.

In Java, implementation classes are always subtype of the
interface class, but they cannot reuse the code in the interface
class, because there is no implementation in the interface.
Without implementation inheritance, it is not easy to provide
the default implementation mechanism for code reuse.

Transframe's multiple interface inheritance plus implementation
delegation provides a perfect way for both subtyping and
implementation reuse. For detail, refer to:

	Multiple Inheritance -- A Critical Comparion
	http://www.sigs.com/publications/docs/oc/9611/oc9611.shang.c.html

David Shang

Re: Eiffel and Java

[Marcos F. F. de Macedo]

Alexander Asteroth wrote:
> 
> Marcos F. F. de Macedo wrote:

> > This kind of interface/implementation in Sather is diferent of the usual
> > concept. This is subtype/subclass independence. That is a good thing in
> > Sather that I have not yet thinked of the exact consequences.
> >
> > Interfaces in Java have nothing to do with this concepts. Interface in
> > Java is an implementation restriction (not a conceptual one) to avoid
> > multiple-inheritance and work yet work with static typing. Interface is
> > java is just a deferred class with just deferred routines. Nothing more,
> > nothing less.
> 
> I don't see your point. What is missing in Java's interfaces.
> 
> If it's that you don't have to touch existing code (as F.H. wrote)
> that has to do with supertyping, not with the abstract classes concept
> of Sather (Or am I completetly wrong here?).
> 
> Can you give an example of what you mean and what you think
> is wrong about Java's interfaces?
> 
Of course I can. Let's make myself clear. When I talk about abstract
classes I talk about the general concept that Yes common to most object
oriented classes (pure virtual in C++, defferred in Eiffel, abstract
class in Smalltalk, virtual in Simula,etc). An abstract class is a
classe that has one or more routines that dont have implementations but
just interface. Such class can not have instances because its behavior
is not defined. Its used to model general class for example. I can have
an abstract class ANIMAL with sub-classes Dog, Cat, Bird. No object will
be direct an animal but one of Dog, Cat or Bird. The abstract serves as
the general model an in a Framework its the root of the main
hierarquies. In static typed languages the abstract class is used to
defined a minimal behavior of subclasses.
Its common to abstract classes to not have all methods abstract but do
define other that class abstract methods over self to give an special
behavior. Such methods are called template and are in the soul of OOP.

The Java interface are just an abstract class with all methods abstract
(no implementation). Its is used because its hard to implement multiple
inheritance when there are attributes. So you can inherit from one class
but multiple inheritance. In languages such as Sather, Eiffel, Beta,
etc... You can made abstract classes with just abstract methods and you
will have the same behavior. But templates can only be done if some
methods are not abstract. The good thing in Java is that you can inherit
one parent (single inheritance) but can inherit multiple interface
(multiple subtyping). In Eiffel you have (multiple-inheritance and
multiple sub-typing).

The type hierarquie in Sather is diferent in that you can put an
interface in a class that was not declared to "implements" it. That can
be a good thing to correct bad design but can be a good thing to make
bad design too. You will have to work with two diferent hierarquies. Its
that necessary? 
(if you want to know how this diferent implementations are done send me
an e-mail).

I hope thar this was not too long but too clear :-)


-- 
Marcos F. F. de Macedo
marcosm@sede.unijui.tche.br
UNIJUI - BRAZIL

Re: Eiffel and Java

[Jon S Anthony]

In article <32821C82.2D32524D@sede.unijui.tche.br> "Marcos F. F. de Macedo" <marcosm@sede.unijui.tche.br> writes:

> Jon S Anthony wrote:
> 
> > Right.  As was pointed out back in that old thread, to get at the
> > "separate" spec/impl aspects in Eiffel you would use an "abstract
> > class" technique.  This doesn't quite work, but it is at least the
> > proper analogue.
> 
> The spec/impl is to separate the way that clients see the class
> (interface) from actual code/structure. This is done in Eiffel by the
> short tool. The short tool generates the interface to an eiffel class
> with more spec. than is done in Ada.

For what is being discussed here - SEPARATION of spec and impl, the short
form for Eiffel is irrelevant.


> There is no need to write the interface if it could be stracted from the
> source code. I should know that Ada was based on Modula-2 that used this
> way of separating. Oberon, the sucessor of Modula-2, uses automatic
> interface generating tool.

No, Ada was not "based on M2".  And if you want to comment on this -
first go back and read the thread to understand why what you're saying
is just nonsense.  After that, maybe you will have something useful to
say...

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Eiffel and Java

[Fergus Henderson]

shang@corp.mot.com (David L. Shang) writes:

]Separation of the interface from implementation is a good thing.
]It is required by the practical software engineering needs to reduce
]the dependency among software components. 
[...]
]But separation subtype from subclass is not.

Why not?  Doesn't this also serve to "reduce the dependency
among software components"?

]In Sather, implementation classes are not always subtype of the
]parent class. They merely reuse the code (inherite the implementation)
]defined in their parent, but not necessarily be subtype of it.
]Without subtyping, the interface provided in the parent cannot
]serve as a polymorphic interface for all the implementations.

Yes, and that's a good thing, isn't it?
It decouples the interface and the implementation,
making it easier to use a different implementation.

]In Java, implementation classes are always subtype of the
]interface class, but they cannot reuse the code in the interface
]class, because there is no implementation in the interface.

So the code is elsewhere, big deal.  They can still
reuse it, can't they?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Eiffel and Java

[Don Harrison]

Marcos F. F. de Macedo writes:

:Jon S Anthony wrote:
:
:> Right.  As was pointed out back in that old thread, to get at the
:> "separate" spec/impl aspects in Eiffel you would use an "abstract
:> class" technique.  This doesn't quite work, but it is at least the
:> proper analogue.

Jon, don't know why you say this. I have some vague recollection of you
talking about Sather's separate interface and implementation *inheritance*.
But Ada doesn't even support that, so I'm not sure what you're thinking
of. Please explain why you make this association.

:The spec/impl is to separate the way that clients see the class
:(interface) from actual code/structure. This is done in Eiffel by the
:short tool. The short tool generates the interface to an eiffel class
:with more spec. than is done in Ada.
:
:There is no need to write the interface if it could be stracted from the
:source code. I should know that Ada was based on Modula-2 that used this
:way of separating. Oberon, the sucessor of Modula-2, uses automatic
:interface generating tool.

I'm with you on this. Your point was raised in the "Real OO" thread Jon 
refers to. 

This is how I would 'match' these facilities in Ada and Eiffel:

Ada                                   Eiffel
---                                   ------
abstract tagged type                  deferred class
abstract operation                    deferred routine

package interface                     (output of short tool)
package body                          class


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Eiffel and Java

[Matt Kennel]

Alexander Asteroth (aster@horz.technopark.gmd.de) wrote:
: Marcos F. F. de Macedo wrote:
:  
: > Fergus Henderson wrote:
: > > base class.  In Sather, one can simply create a new interface and
: > > declare these classes to be instances of this interface, without
: > > modifying the existing code.
:  
: > This kind of interface/implementation in Sather is diferent of the usual
: > concept. This is subtype/subclass independence. That is a good thing in
: > Sather that I have not yet thinked of the exact consequences.
: > 
: > Interfaces in Java have nothing to do with this concepts. Interface in
: > Java is an implementation restriction (not a conceptual one) to avoid
: > multiple-inheritance and work yet work with static typing. Interface is
: > java is just a deferred class with just deferred routines. Nothing more,
: > nothing less.

: I don't see your point. What is missing in Java's interfaces.

Genericity, of course, and post-hoc supertyping. 

: If it's that you don't have to touch existing code (as F.H. wrote) 
: that has to do with supertyping, not with the abstract classes concept
: of Sather (Or am I completetly wrong here?). 

".... This, I tell you brother/ 
      you can't have one without the other, "

: Alexander Asteroth

--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 
  I would not, could not SAVE ON PHONE,    |==================================
  I would not, could not BUY YOUR LOAN,    |The US Government does not like
  I would not, could not MAKE MONEY FAST,  |spam either.  It is ILLEGAL!
  I would not, could not SEND NO CA$H,     |USC Title 47, section 227
  I would not, could not SEE YOUR SITE,    |p (b)(1)(C) www.law.cornell.edu/
  I would not, could not EAT VEG-I-MITE,   | /uscode/47/227.html
  I do *not* *like* GREEN CARDS AND SPAM!  |==================================
               M A D - I - A M!

Re: Eiffel and Java

[Alexander Asteroth]

Marcos F. F. de Macedo wrote:
 
> Fergus Henderson wrote:
> > base class.  In Sather, one can simply create a new interface and
> > declare these classes to be instances of this interface, without
> > modifying the existing code.
 
> This kind of interface/implementation in Sather is diferent of the usual
> concept. This is subtype/subclass independence. That is a good thing in
> Sather that I have not yet thinked of the exact consequences.
> 
> Interfaces in Java have nothing to do with this concepts. Interface in
> Java is an implementation restriction (not a conceptual one) to avoid
> multiple-inheritance and work yet work with static typing. Interface is
> java is just a deferred class with just deferred routines. Nothing more,
> nothing less.

I don't see your point. What is missing in Java's interfaces.

If it's that you don't have to touch existing code (as F.H. wrote) 
that has to do with supertyping, not with the abstract classes concept
of Sather (Or am I completetly wrong here?). 

Can you give an example of what you mean and what you think
is wrong about Java's interfaces? 

Alexander Asteroth

Re: Eiffel and Java

[David L. Shang]

In article <5694r8$c9c@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus  
Henderson) writes:
> shang@corp.mot.com (David L. Shang) writes:
> > But separation subtype from subclass is not [good].
> 
> Why not?  Doesn't this also serve to "reduce the dependency
> among software components"?
>
No, the separation subtype from subclass does not help
dependency reduction. Let "A" be a parent class, and "B" be
a subclass but not a subtype. "C" cannot use "B" unless it is
dependent on "B", because depending on "A" does not provide
any polymorphism that can guide the implementation to "B".

However, it helps subclass reuse the code in its parent class
by violating the constraining requirement regulated by its
parent. That is why I say that it is not good.

When a subclass has to violate the regulation, either the subclass
should not be a child, or the parent class provides a wrong
regulation. 
 
> ]In Sather, implementation classes are not always subtype of the
> ]parent class. They merely reuse the code (inherite the implementation)
> ]defined in their parent, but not necessarily be subtype of it.
> ]Without subtyping, the interface provided in the parent cannot
> ]serve as a polymorphic interface for all the implementations.
> 
> Yes, and that's a good thing, isn't it?
> It decouples the interface and the implementation,
> making it easier to use a different implementation.
> 
As I stated above, it does not make it easier to use a different
implementation, rather, it makes it easier to create a
different implementation that is not a subtype, or that
violates the parent's regulation.

> ]In Java, implementation classes are always subtype of the
> ]interface class, but they cannot reuse the code in the interface
> ]class, because there is no implementation in the interface.
> 
> So the code is elsewhere, big deal.  They can still
> reuse it, can't they?
> 
Let's check the client-server architecture.

If Server provides only the interface, then the clients
must provide all the implementation. No reuse.

If Server provides an interface as well as a default implementation
or a set of alternative implementations by a number of subclasses
of the interface, and if the client wants to reuse the implementation
by subclassing, it must inherit the implementation subclass provided
by the sever. If server's implementation changes, the client changes
because it is dependent on the implementation class.

Therefore, the client must reuse the code by aggregation, or by
a "use" relation, not by a "is-a" relation.

Let "A" be the interface, and "B" be the implementation in the
sever. In client, if we want a subclass of "A" to reuse the code
of "B" without dependent on "B", we have to write:

	class C inherit A  // cannot inherit B
	{
		private A imp;
		public void A_method1(...) { imp.A_method1(...); };
		public int A_method2(...) { return imp.A_method2(...); };
		...
		A()
		{
			imp = new B;
		};
	};

It's kind of cumbersome, isn't it? When mutiple inheritance
is invovled, the situition is even more complicated.

Transframe's multiple interface inheritance plus implementation
delegation provides a perfect way for both subtyping and
implementation reuse.

Let A1, A2, A3, ... be the interfaces, and B1, B2, B3 be the
implementations in the sever. In client, if we want a subclass
of  A1, A2, A3, ... to reuse the code of B1, B2, B3 without
dependent on B1, B2, B3, we can simply write:

	class C is A1 by B1, A2 by B2, A3 by B3,...;

For detail, refer to:

	Multiple Inheritance -- A Critical Comparion
	http://www.sigs.com/publications/docs/oc/9611/oc9611.shang.c.html

David Shang

Re: Eiffel and Java

[David L. Shang]

In article <1996Nov12.143451.16691@schbbs.mot.com> shang@corp.mot.com (David L.  
Shang) writes:
> Let A1, A2, A3, ... be the interfaces, and B1, B2, B3 be the
> implementations in the sever. In client, if we want a subclass
> of  A1, A2, A3, ... to reuse the code of B1, B2, B3 without
> dependent on B1, B2, B3, we can simply write:
> 
> 	class C is A1 by B1, A2 by B2, A3 by B3,...;
> 

Note that C is dependent only on A1, A2, A3,..., but not on
B1, B2, B3,.... Server can change or replace the implementation
without affecting the client applications.

Such implementations can be supplied by other clients. The client
"C1" can use the implementation provided by the client "C2" without
dependent on "C2". This makes dynamic software components much
easier. 

> For detail, refer to:
> 
> 	Multiple Inheritance -- A Critical Comparion
> 	http://www.sigs.com/publications/docs/oc/9611/oc9611.shang.c.html
> 
> David Shang
> 

Re: Eiffel and Java

[Benedict A. Gomes]

In article <328831DB.47C86C44@horz.technopark.gmd.de>,
Alexander Asteroth  <aster@horz.technopark.gmd.de> wrote:
> 
>> This kind of interface/implementation in Sather is diferent of the usual
>> concept. This is subtype/subclass independence. That is a good thing in
>> Sather that I have not yet thinked of the exact consequences.
>> 
>> Interfaces in Java have nothing to do with this concepts. Interface in
>> Java is an implementation restriction (not a conceptual one) to avoid
>> multiple-inheritance and work yet work with static typing. Interface is
>> java is just a deferred class with just deferred routines. Nothing more,
>> nothing less.
>
>I don't see your point. What is missing in Java's interfaces.
>
	The main difference is that in Sather (and Sather-K) it is
possible to inherit implementation without becoming a
subtype. Philosophically, code inheritance was viewed as a structured
macro like facility, an editing tool, and very much secondary to the
abstraction relationships.

ben

 

Re: Eiffel and Java

[Norman H. Cohen]

Don Harrison wrote:

> Jon, don't know why you say this. I have some vague recollection of you
> talking about Sather's separate interface and implementation *inheritance*.
> But Ada doesn't even support that, so I'm not sure what you're thinking
> of. Please explain why you make this association.

Ada DOES support separate interface and implementation inheritance:

   package Interface is
      type Interface_Type is abstract tagged ...;
      ...
   end Interface;

   package Parent_Implementation is
      type Parent_Implementation_Type is
         new Interface.Interface_Type with ...;
      ...
   end Parent_Implementation;

   package Child_Implementation is
      type Child_Implementation_Type is 
         new Interface.Interface_Type with private;
      ...
   private
      type Child_Implementation_Type is 
         new Parent_Implementation.Parent_Implementation_Type
            with ...;
   end Child_Implementation;

The declaration of Child_Implementation_Type in the visible part of the
package declares this type to be descended from Interface_Type, and this
is all that a client of the Child_Implementation package knows about the
type.  The full declaration of Child_Implementation_Type in the private
part indicates that Child_Implementation_Type implements the
Interface_Type interface by inheriting from a particular descendant of
Interface_Type, namely Parent_Implementation_Type.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Eiffel and Java

[Jon S Anthony]

In article <E0qMJC.EJt@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Marcos F. F. de Macedo writes:
> 
> :Jon S Anthony wrote:
> :
> :> Right.  As was pointed out back in that old thread, to get at the
> :> "separate" spec/impl aspects in Eiffel you would use an "abstract
> :> class" technique.  This doesn't quite work, but it is at least the
> :> proper analogue.
> 
> Jon, don't know why you say this. I have some vague recollection of you
> talking about Sather's separate interface and implementation *inheritance*.
> But Ada doesn't even support that, so I'm not sure what you're thinking
> of. Please explain why you make this association.

Don, what on Earth are you talking about?

First, we are speaking of interface/impl _separation_.  This was
discussed to death in the Real OO thread.  There are several reasons
why a) the "abstract class" trick in Eiffel is the correct analogue
and b) it doesn't quite work.  In fact, you _agreed_ with this!  See
below...

Second, where do you get the idea that Ada doesn't support separation
of interface and implementation inheritance????  Of course it does.
This is _another_ thing that was pointed out several times in several
ways by several people.  The implementation of a types interface can
be done completely separately from any aspects it might inherit or not
from its parent type.  It may in fact not use _any_ of its parent's
operations in this implementation.  You may also have a case where you
have the interface inherit some of the parent's implementation while
defining new operations which will be implemented using other parts of
the parent's implementation which are not part of the interface.


> :There is no need to write the interface if it could be stracted from the
> :source code. I should know that Ada was based on Modula-2 that used this
> :way of separating. Oberon, the sucessor of Modula-2, uses automatic
> :interface generating tool.
> 
> I'm with you on this. Your point was raised in the "Real OO" thread Jon 
> refers to. 

Correct and I recall that it became pretty clear to all what the
issues were and why the two approaches (not separating and using a
"short tool/form" and separating as in Ada...) were substantially
different.  For an example of the discussion, see below...


> This is how I would 'match' these facilities in Ada and Eiffel:
> 
> Ada                                   Eiffel
> ---                                   ------
> package interface                     (output of short tool)

Nope...  The output of the short tool does not get fed to an Eiffel
compiler and in no way is a language entity.  You can't give a "short
form" several different implementations, etc.

> package body                          class

Nope.  As you by now know, an Eiffel class is (more or less)
equivalent to a package exporting a tagged type interface.  Now, in
Ada, you can implement this type's interface in various ways -
including those where the



OK, I actually went back and found a couple of relevant articles:

---Partial article from me replying to mbk replying to someone...

> >  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).



---Full article of donh reply to me...

Subject:      Re: Real OO (was Choice of OO primitives in Ada95)
From:         donh@syd.csa.com.au (Don Harrison)
Date:         1996/03/11
Message-Id:   <Do3FLw.50H@assip.csasyd.oz>
Sender:       news@assip.csasyd.oz
References:   <JSA.96Mar8143939@organon.com>
Organization: CSC Australia
Reply-To:     donh@syd.csa.com.au
Newsgroups:   comp.lang.ada,comp.lang.eiffel,comp.object

Jon S Anthony writes:

:In article <313F3415.F5A@venice.sedd.trw.com> "Matthew M. Lih" <lih@venice.sedd.trw.com> writes:
:
:> Another thing you can do in Ada is specify multiple implementations.
:> The common use of this is to have an implementation which returns
:> "dummy" results which people can use to test code which uses the
:> procedure. Meanwhile, the implementor can work on the actual
:> implementation. Is this possible in Eiffel?
:
:Sure, but it is either a) more complicated, b) more dodgy or c) both.
:If you play the "abstract class" game (and write protect the file,
:ugh!) you can sort of crib this as the "abstract class" is a kind of
:"poor mans" package specification.  Of course, you now have two
:interfaces to deal with: the "abstract one" and the
:"actual/implementation" one.

I agree. (That scared you, didn't it? :-)

:The other course is to have two
:implementations: the "fake" one and the "real" one.  You then must
:trust the implementor of the "real" one to not change the interface.

... or use tools to control it?

:/Jon
:-- 
:Jon Anthony
:Organon Motives, Inc.
:1 Williston Road, Suite 4
:Belmont, MA 02178
:
:617.484.3383
:jsa@organon.com

Don

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Eiffel and Java

[Don Harrison]

Norman H. Cohen writes:

:Ada DOES support separate interface and implementation inheritance:
:
:   package Interface is
:      type Interface_Type is abstract tagged ...;
:      ...
:   end Interface;
:
:   package Parent_Implementation is
:      type Parent_Implementation_Type is
:         new Interface.Interface_Type with ...;
:      ...
:   end Parent_Implementation;
:
:   package Child_Implementation is
:      type Child_Implementation_Type is 
:         new Interface.Interface_Type with private;
:      ...
:   private
:      type Child_Implementation_Type is 
:         new Parent_Implementation.Parent_Implementation_Type
:            with ...;
:   end Child_Implementation;
:
:The declaration of Child_Implementation_Type in the visible part of the
:package declares this type to be descended from Interface_Type, and this
:is all that a client of the Child_Implementation package knows about the
:type.  The full declaration of Child_Implementation_Type in the private
:part indicates that Child_Implementation_Type implements the
:Interface_Type interface by inheriting from a particular descendant of
:Interface_Type, namely Parent_Implementation_Type.

My error. I'm just going to simplify your example and put in some detail to 
see how you get hold of a 'covariant' operation. (Hope you don't mind). 

Assuming D_Type inherits from C_Type (and omitting various syntactic details),

   package A_Module is
      type A_Type is tagged ...;
      procedure op (a: A_Type; c: C_Type'Class);
      ...
   end A_Module;

   package B_Module is
      type B_Type is new A_Module.A_Type with private;
      procedure op (b: B_Type; c: C_Type'Class);   -- Overridden op
      procedure op (b: B_Type; d: D_Type'Class);   -- New, 'covariant' op
      ...
   private
      type B_Type is new A_Module.A_Type with ...;
   end B_Module;

   package body B_Module is
      procedure op (b: B_Type; c: C_Type'Class) is
      begin
        op (b, D_Type(c) );   -- No dispatching; Is this valid?
      exception
        when others => raise; -- chuck a wobbly!
      end;

      procedure op (b: B_Type; d: D_Type'Class) is ...
      ...
   end B_Module;

Is this how it works?


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Eiffel and Java

[Don Harrison]

Jon S Anthony writes:

:First, we are speaking of interface/impl _separation_.  This was
:discussed to death in the Real OO thread.  There are several reasons
:why a) the "abstract class" trick in Eiffel is the correct analogue
:and b) it doesn't quite work.  In fact, you _agreed_ with this!  See
:below...

Well, it may have appeared that way to you (for a good reason) but wasn't 
the case. See below.

:Second, where do you get the idea that Ada doesn't support separation
:of interface and implementation inheritance????  Of course it does.
:This is _another_ thing that was pointed out several times in several
:ways by several people.  The implementation of a types interface can
:be done completely separately from any aspects it might inherit or not
:from its parent type.  It may in fact not use _any_ of its parent's
:operations in this implementation.  You may also have a case where you
:have the interface inherit some of the parent's implementation while
:defining new operations which will be implemented using other parts of
:the parent's implementation which are not part of the interface.

Yes, I appear to be wrong on this. I suspect this is different to how it
works in other languages (eg. Sather, Cecil) but that's another matter.
Actually, Sather's approach of using 'abstract' and 'concrete' classes is
probably your source of confusion. I don't know much about Sather but
I *do* know that it's abstract classes *are* used to define interfaces.
This is not the purpose of Eiffel deferred classes as I explain below.

:Correct and I recall that it became pretty clear to all what the
:issues were and why the two approaches (not separating and using a
:"short tool/form" and separating as in Ada...) were substantially
:different.  

When you say 'clear to all', I presume you're speaking on my behalf as well. 
I'll represent myself, if you don't mind. :(

For an example of the discussion, see below...

:> This is how I would 'match' these facilities in Ada and Eiffel:
:> 
:> Ada                                   Eiffel
:> ---                                   ------
:> package interface                     (output of short tool)
:
:Nope...  The output of the short tool does not get fed to an Eiffel
:compiler and in no way is a language entity.  You can't give a "short
:form" several different implementations, etc.

As you suggest, another use of separate interfaces is to facilitate separate
compilation. But the primary purpose of an interface is to provide a view of 
the abstraction and, for the Eiffel developer, that is provided by the short 
form. For separate compilation, the Eiffel system can generate a notional 
interface from the class text. This 'interface' can then be used in conjunction 
with the CM system to do all those nice things that you can do in Ada (eg. 
substitute a different implementation such as a stub). The Eiffel system might 
do this by generating the notional interface whenever a class is compiled and 
comparing it with the existing one (if any). If different, and the developer 
gives the go ahead, the notional interface can be updated. The CM repository 
can be used to hold different implementations of the same interface.
I don't know whether any Eiffel implementations provide this facility but
they should, IMO. As you know, this is very useful.

So, it is more accurate to say 

Ada spec (analogous to) Eiffel notional interface + short form.

:> package body                          class
:
:Nope.  As you by now know, an Eiffel class is (more or less)
:equivalent to a package exporting a tagged type interface.  Now, in
:Ada, you can implement this type's interface in various ways -
:including those where the

Yes, my comparison is inaccurate. Remembering that the Eiffel interface is
notional, the comparison should be more like

Ada spec + body + single enclosed tagged type (analogous to) Eiffel class.


:---Full article of donh reply to me...
:
:Subject:      Re: Real OO (was Choice of OO primitives in Ada95)
:From:         donh@syd.csa.com.au (Don Harrison)
:Date:         1996/03/11
:Message-Id:   <Do3FLw.50H@assip.csasyd.oz>
:Sender:       news@assip.csasyd.oz
:References:   <JSA.96Mar8143939@organon.com>
:Organization: CSC Australia
:Reply-To:     donh@syd.csa.com.au
:Newsgroups:   comp.lang.ada,comp.lang.eiffel,comp.object
:
:Jon S Anthony writes:
:
::In article <313F3415.F5A@venice.sedd.trw.com> "Matthew M. Lih" <lih@venice.sedd.trw.com> writes:
::
::> Another thing you can do in Ada is specify multiple implementations.
::> The common use of this is to have an implementation which returns
::> "dummy" results which people can use to test code which uses the
::> procedure. Meanwhile, the implementor can work on the actual
::> implementation. Is this possible in Eiffel?

BTW, this is what I'm suggesting *can* be done.

::Sure, but it is either a) more complicated, b) more dodgy or c) both.
::If you play the "abstract class" game (and write protect the file,
::ugh!) you can sort of crib this as the "abstract class" is a kind of
::"poor mans" package specification.  Of course, you now have two
::interfaces to deal with: the "abstract one" and the
::"actual/implementation" one.
:
:I agree. (That scared you, didn't it? :-)

Well, I have a confession to make to you, Jon. After 4-5 months of arguing
with you, I was fairly receptive to agreeing with anything you said - true 
or otherwise. In this case, I did agree with a little of what you said but 
not all. :)  I wasn't more specific because I was anxious to put an end to
the interminable argument so didn't want to provide more fuel for it. :(

Come to think of it, there isn't a lot in there I *do* agree with. :) 
It must have just been that using abstract classes to emulate separate
interfaces is misguided (dodgy). In fact, it's a misuse of abstract
classes. The point to realise is that languages are designed to do similar 
things in different ways. Using deferred classes in Eiffel to emulate separate interfaces, is misuse just as attempting to use Ada's information hiding 
mechanisms to simulate selective export is misuse. (The correct approach for 
Ada is to put all the closely-related types in the same package, as Norman 
Cohen pointed out. It isn't quite the same but it's the proper way of doing 
it in Ada).

Now, back to why deferred classes are not the analogue of separate 
interfaces. It has to do with the purpose of each. The purpose of Ada package 
specs is to provide a view to clients of the services of the abstraction and
to allow separate compilation. However, the purpose of abstract (deferred) 
classes is to provide a (possibly partially implemented) design template for 
a general abstraction. In doing so, it happens to define the interface to the 
abstraction but it also defines any implementation of parts of that abstraction. 
It also happens to confer the interface upon heirs but this is true of any parent 
class; it is not peculiar to abstract classes.

So, in terms of intended purpose, Eiffel deferred classes have more in 
common with Ada's abstract types. Also, the short form and notional interface
collectively offer similar functionality to package specs.

I hope this clarifies my position.

::The other course is to have two
::implementations: the "fake" one and the "real" one.  You then must
::trust the implementor of the "real" one to not change the interface.
:
:.... or use tools to control it?

This is an allusion to the Eiffel system managing different implementations
of a class in conjunction with the CM system.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Eiffel and Java

[Paul Johnson]

In article <1996Nov11.142547.4810@schbbs.mot.com>, shang@corp.mot.com says...
>
>In article <328592FC.64F26D66@sede.unijui.tche.br> "Marcos F. F. de Macedo"  
><marcosm@sede.unijui.tche.br> writes:

>> Interfaces in Java have nothing to do with this concepts. Interface in
>> Java is an implementation restriction (not a conceptual one) [...]

>Separation of the interface from implementation is a good thing.
>It is required by the practical software engineering needs to reduce
>the dependency among software components. 

Maybe, but along the way from interface to implementation there is space for 
partial implementations containing code that is reused between the final 
implementations.

A good example is the Eiffel "COMPARABLE" class, which defines all the 
comparison operators in terms of the "<" operator.  So for instance the 
implementation of ">=" is

   Result := not Current < other;

You can't do this in Java: every class that wants comparison operators 
(assuming such a thing can be defined in the language) needs to implement all 
of them every time.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Eiffel and Java

[Fergus Henderson]

shang@corp.mot.com (David L. Shang) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>> shang@corp.mot.com (David L. Shang) writes:
>> > But separation subtype from subclass is not [good].
>> 
>> Why not?  Doesn't this also serve to "reduce the dependency
>> among software components"?
>
>No, the separation subtype from subclass does not help
>dependency reduction. Let "A" be a parent class, and "B" be
>a subclass but not a subtype. "C" cannot use "B" unless it is
>dependent on "B", because depending on "A" does not provide
>any polymorphism that can guide the implementation to "B".

In this situation, a Sather programmer would make an interface $A
that was a supertype of B, and then C could use B via the $A interface.

	interface $A > B is ...  end;

	class C < $A is
		private include B;
		...
	end;

If you want the compiler to make sure that C does not depend on B,
you can encapsulate the dependency on B as follows:

	class C_A < $A is private include B end;

	class C < $A is
		private include C_A;
		...
	end;

Later another programmer could change things so
that C used any other class B2 < $A instead of B,
just by changing the one-line definition of C_A.

This seems much better than languages such as C++ or Eiffel which don't
separate subtype and subclass inheritence, where a programmer would
probably make C access B via A rather than $A.  If A is not an abstract
interface, this makes it difficult to change the program to use a
different implementation.

So I think separating subtype from subclass does serve to
reduce the dependency among software components.

>> ]In Sather, implementation classes are not always subtype of the
>> ]parent class. They merely reuse the code (inherite the implementation)
>> ]defined in their parent, but not necessarily be subtype of it.
>> ]Without subtyping, the interface provided in the parent cannot
>> ]serve as a polymorphic interface for all the implementations.
>> 
>> Yes, and that's a good thing, isn't it?
>> It decouples the interface and the implementation,
>> making it easier to use a different implementation.
>> 
>As I stated above, it does not make it easier to use a different
>implementation,

I think it does.  Requiring people to use only abstract interfaces
for polymorphism does make it easier to use different implementations.

>rather, it makes it easier to create a
>different implementation that is not a subtype, or that
>violates the parent's regulation.

If you said "as well" rather than "rather", then I might agree with you.

But I'm not yet convinced that creating a different implementation that is
not a subtype is necessarily a bad thing, in a language which separates
subtyping and subclassing.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Eiffel and Java

[Kai Quale]

In article <1996Nov12.143451.16691@schbbs.mot.com>, shang@corp.mot.com wrote:

> However, it helps subclass reuse the code in its parent class
> by violating the constraining requirement regulated by its
> parent. That is why I say that it is not good.
> 
> When a subclass has to violate the regulation, either the subclass
> should not be a child, or the parent class provides a wrong
> regulation. 

How does separation of subtype from subclass help a subclass in violating
the constraining requirement regulated by its parent ? Btw, by "parent",
do you mean its supertype or superclass ?

From what I know of Sather:

* (Abstract) types/interfaces have only type constraints.
  The Sather compiler will not allow a class to break the type constraints
  of its supertypes. 

* (Concrete) classes may have invariants and such.
  - If a (concrete) class inherits an invariant from its superclass, it
    cannot break it anymore than its superclass can.
  - If it doesn't inherit the invariant (and assuming it doesn't re-
    implement it), it doesn't HAVE the invariant (and as such can't
    break it).

Sather people, have I got this right ?

kai

-- 
Kai Quale
USIT, University of Oslo
email: Kai.Quale@usit.uio.no

Re: Eiffel and Java

[David L. Shang]

In article <56j7up$h1n@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus  
Henderson) writes:

> shang@corp.mot.com (David L. Shang) writes:
> >No, the separation subtype from subclass does not help
> >dependency reduction. Let "A" be a parent class, and "B" be
> >a subclass but not a subtype. "C" cannot use "B" unless it is
> >dependent on "B", because depending on "A" does not provide
> >any polymorphism that can guide the implementation to "B".
> 
> In this situation, a Sather programmer would make an interface $A
> that was a supertype of B, and then C could use B via the $A interface.
> 
> 	interface $A > B is ...  end;
> 
> 	class C < $A is
> 		private include B;
> 		...
> 	end;
>

Here you evaded the question. It is not the separation but the
delegation in your example that helps the reduction of the
dependency. Transframe supports automatic delegation: you are
not necessary to delegate all the methods manually. Just write:

	class C is A by B;

Separation is not necessary. B is subtype of A; C is subtype of
A; but C is not subtype, nor subclass of of B.

> If you want the compiler to make sure that C does not depend on B,
> you can encapsulate the dependency on B as follows:
> 
> 	class C_A < $A is private include B end;
> 
> 	class C < $A is
> 		private include C_A;
> 		...
> 	end;
> 
> Later another programmer could change things so
> that C used any other class B2 < $A instead of B,
> just by changing the one-line definition of C_A.
> 
> This seems much better than languages such as C++ or Eiffel which don't
> separate subtype and subclass inheritence, where a programmer would
> probably make C access B via A rather than $A.  If A is not an abstract
> interface, this makes it difficult to change the program to use a
> different implementation.
> 
> So I think separating subtype from subclass does serve to
> reduce the dependency among software components.
> 

Again, you miss the nail head. The purpose of Sather's separation
is not for the reduction of dependency, but for allowing subclass
to have covariant constraints, i.e. to have presumptions that violates
the specification in its parent class. 

Using delegation manually in C++ and Effel, you can reduce
the dependency in the same way as you did in Sather.

David Shang

Re: Eiffel and Java

[David L. Shang]

In article <Kai.Quale-1811962012430001@macusit36.uio.no> Kai.Quale@usit.uio.no  
(Kai Quale) writes:
> How does separation of subtype from subclass help a subclass in violating
> the constraining requirement regulated by its parent ?

Exactly by allowing subclass not being a subtype. When it violates,
it cannot be a subtype, but it still can be a subclass.

> Btw, by "parent",
> do you mean its supertype or superclass ?
> 

Hence the "parent" is the superclass in general.

David Shang

Re: Eiffel and Java

[Jon S Anthony]

In article <E0wCD9.GDo@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
> :Second, where do you get the idea that Ada doesn't support separation
> :of interface and implementation inheritance????  Of course it does.
> :This is _another_ thing that was pointed out several times in several
> :ways by several people.  The implementation of a types interface can
> :be done completely separately from any aspects it might inherit or not
> :from its parent type.  It may in fact not use _any_ of its parent's
> :operations in this implementation.  You may also have a case where you
> :have the interface inherit some of the parent's implementation while
> :defining new operations which will be implemented using other parts of
> :the parent's implementation which are not part of the interface.
> 
> Yes, I appear to be wrong on this. I suspect this is different to how it
> works in other languages (eg. Sather, Cecil) but that's another matter.
> Actually, Sather's approach of using 'abstract' and 'concrete' classes is
> probably your source of confusion. I don't know much about Sather but
> I *do* know that it's abstract classes *are* used to define interfaces.
> This is not the purpose of Eiffel deferred classes as I explain below.

Well - yes, I know that is how Sather works in this area.  I meant
that in the Eiffel case you would have to fake this with a class which
you happen to "really implement" by means of another separate class.
I am not talking about Eiffel deferred classes here per se and is why
I used the scare quotes around "abstract class".  I was the one saying
that these are DIFFERENT.  Go back and check out the thread.


> :Correct and I recall that it became pretty clear to all what the
> :issues were and why the two approaches (not separating and using a
> :"short tool/form" and separating as in Ada...) were substantially
> :different.  
> 
> When you say 'clear to all', I presume you're speaking on my behalf as well. 
> I'll represent myself, if you don't mind. :(

So, you don't think the approaches _are_ different?????????!?!?!?!
I'm not saying any one ever agreed on what was "right" - just that
they are in fact different!  I can't imagine how anyone could say they
are the same.  But you never know...


> As you suggest, another use of separate interfaces is to facilitate
> separate compilation. But the primary purpose of an interface is to
> provide a view of the abstraction and, for the Eiffel developer,
> that is provided by the short form. For separate compilation, the
> Eiffel system can generate a notional interface from the class
> text. This 'interface' can then be used in conjunction with the CM
> system to do all those nice things that you can do in Ada (eg.
> substitute a different implementation such as a stub). 

Well, I wouldn't say "all" - there is no way to semantically check
this stuff is consistent across its potential clients (well probably
not - unless the add on tools understood Eiffel semantics as well as
an Eiffel compiler).

> The Eiffel system might do this by generating the notional interface
> whenever a class is compiled and comparing it with the existing one
> (if any). If different, and the developer gives the go ahead, the
> notional interface can be updated. The CM repository can be used to
> hold different implementations of the same interface.  I don't know
> whether any Eiffel implementations provide this facility but they
> should, IMO. As you know, this is very useful.

Agreed.


> Ada spec + body + single enclosed tagged type (analogous to) Eiffel class.

Agreed.


> :---Full article of donh reply to me...
>[snip...]
>
> Well, I have a confession to make to you, Jon. After 4-5 months of arguing
> with you, I was fairly receptive to agreeing with anything you said - true 
> or otherwise. In this case, I did agree with a little of what you said but 
> not all. :)  I wasn't more specific because I was anxious to put an end to
> the interminable argument so didn't want to provide more fuel for it. :(

Sounds reasonable.


> interfaces is misguided (dodgy). In fact, it's a misuse of abstract
> classes.

Agreed.  But it is about the only way with current out of the box
Eiffel to get this sort of capability.

> The point to realise is that languages are designed to do similar
> things in different ways. Using deferred classes in Eiffel to
> emulate separate interfaces, is misuse 

Agreed.


> just as attempting to use Ada's information hiding mechanisms to
> simulate selective export is misuse. (The correct approach for Ada
> is to put all the closely-related types in the same package, as
> Norman Cohen pointed out. It isn't quite the same but it's the
> proper way of doing it in Ada).

The only way to get selective export (in a limited form) in Ada is
with child units.  This works fine and is a proper use but is not as
general as the Eiffel approach.  But I see your intent here and
basically agree with it.


> So, in terms of intended purpose, Eiffel deferred classes have more in 
> common with Ada's abstract types.

Absolutely - and I never said otherwise.  You have apparently mistook
my "abstarct class" notation as referring to Eiffel _deferred classs_.
Not so.


> Also, the short form and notional interface collectively offer
> similar functionality to package specs.

Well - if all that other machinery existed, this would be true.  But
even then, it would not be part of the Eiffel language - rather add on
tools.


> I hope this clarifies my position.

Yip.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Eiffel and Java

[Don Harrison]

Jon Anthony writes:

:Well - yes, I know that is how Sather works in this area.  I meant
:that in the Eiffel case you would have to fake this with a class which
:you happen to "really implement" by means of another separate class.

You wouldn't *want* to try to fake it simply because you don't need to. 
Trying to fake it is like attempting to cut a tree down with a chainsaw by 
bashing the sharp end against the tree just because you're used to using an 
axe - in other words, using a tool in a different way from that intended.

:So, you don't think the approaches _are_ different?????????!?!?!?!

No, they are obviously different.

I am disagreeing with the claim that everyone involved in that discussion 
(about the benefits or otherwise of separating interface from implementation) 
agreed on what the issues were. They did not. Some people thought particular 
things were relevant to the issue which others (maybe only myself) considered irrelevant. There was no general agreement on what the issues were.

(I don't accept that it is necessary to explicitly separate interface and 
implementation to acheive 1) Type safety, 2) Separate compilation, 
3) Whatever else). :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: Eiffel and Java

[Van Snyder]

In article <1996Oct31.202857.3481@merlin.hgc.edu> jcm@hgc.edu (James McKim) writ
es:
>In article <E02IMv.I9M@syd.csa.com.au> donh@syd.csa.com.au writes:
>>Matthew Heaney writes:
>
>[..]
>
>>
>>
>>: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
>>Eiffel because it is a pure, single-dispatched language. For such
>>languages, it makes sense to isolate the dispatching parameter to show that
>>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
>>
>>In any case, truly symmetric operations are relatively few, IMO.
>
>In an article in the 10/94 issue of JOOP, Richie Bielak and I argued that
>such features should really be creation routines in class SET.
>
>IMHO, the dot notation and the desire for symmetry are almost orthogonal
>issues. For better or for worse many library classes for languages that support
>the dot notation have chosen to design intrinsically symmetric operations in
>an asymmetric way, but that is not the only way.

In Mesa, a.b.c and c(b,a) and c(b(a)) were entirely equivalent.  The author
could use whatever syntax he hoped would most help the reader understand
his frame of mind at the instant he wrote the code.

This worked no matter whether "c" was a function, or a "data member" of
the class a.b.

To make the symmetry complete, one could define "updaters," that is,
procedures that could appear on the left of an assignment operator, or
be bound to procedure arguments of "out" or "input" mode.  These were
different from "left hand functions" as described by Aho et. al.:  The
procedure received the value to be "absorbed," exactly antisymmetrically
to the way a function works.

As a side effect, one could change the representation of an object from
record field to procedure, or array element to procedure, or array
element to record field, ... without any change in the referential
syntax. See Geschke and Mitchell, "On the problem of uniform references
to data structures," IEEE TSE SE-1, 2 (1975).

Too bad the work was done at Xerox.
-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: Eiffel and Java

[Kai Quale]

In article <1996Nov18.223239.21147@schbbs.mot.com>, shang@corp.mot.com wrote:

> In article <Kai.Quale-1811962012430001@macusit36.uio.no>
Kai.Quale@usit.uio.no  
> (Kai Quale) writes:
> > How does separation of subtype from subclass help a subclass in violating
> > the constraining requirement regulated by its parent ?
> 
> Exactly by allowing subclass not being a subtype. When it violates,
> it cannot be a subtype, but it still can be a subclass.

A subclass has SOME supertype(s) - if nothing is given it defaults to $OB.
This means it inherits INTERFACE from the supertype(s). Being a subclass,
it also inherits CODE from superclass(es). The superclasses however, don't
have to have the same name as the supertypes.

Result: The subclass inherits TYPE constraints from its supertype(s), and
other constraints from its superclass(es). It cannot violate either.
Where's the problem ?

kai

-- 
Kai Quale
USIT, University of Oslo
email: Kai.Quale@usit.uio.no