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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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 + Ada dispatching

[Jean-Marc Jezequel]

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

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

What do you mean? Conceptually it *is* (can be though of as) a field of the object
(if I gather well what you mean by field). That it uses to not be at runtime is a 
compiler optimization. Or do you mean something else?


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

The problem is much more profound, because if you have single dispatch only, it *is*
"special" somehow, whatever the syntax you use to write it.
For binary operations, it seems that there is no other way
that double-dispatch (built in as in CLOS, or emulated as everywhere else).
Check e.g. the recent article "On Binary Methods" by Bruce, Cardelli et al. in 
Theory and Practice of Object System. Static binding of one of the paramater poses
problem, and in this respect Ada95 does not bring anything new (and in this respect is no
better than C++/Java/Eiffel/Sather etc.). Prove me wrong, please, and win a paper in TPOS.
But please, do not quote me outside of the context this time.

BTW you could write: set_c := set_a + set_b in Eiffel, with the declaration
infix "+" (other: SET): SET is
-- returns union of Current and Other
...

but unless you redispatch on the dynamic type of 'other', it does not solve
the problem.

>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

I have trouble understanding these sentences. Could you please reformulate
in English or even American English?

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

Well, I still cannot see what it buys you beyond being able to choose 
at *compile time* (i.e. statically) the position of the parameter that receives
the dispatch (big deal, IMHO) ? Or do you mean something else?
In that case, please give us a more complete example. Or would a real
Ada95 expert tell us? (Yvon, are you still there?)


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


Dealing with binary methods whose both arguments can be instances of subtypes of the declared
types is *not* a "simple and ordinary thing". Again, if you have such a simple solution,
tell us! I'll praise you then.

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

How can you say that? I agree that they are quite commonplace in math-related software
(linear algebra, sets etc.), and could sometimes appear in other pieces, but not to the
point of being ubiquitous. But that's not the point. Well, what is your point anyway?

---
Jean-Marc Jezequel               | Tel : +81 (3) 3812-2111 ext. 4116
IRISA/CNRS, currently visiting:  | Fax : +81 (3) 5689-4365
Dept. of Information Science     | e-mail : jezequel@irisa.fr  or
Faculty of Science               | e-mail : jezequel@is.s.u-tokyo.ac.jp
The University of Tokyo          | http://www.irisa.fr/pampa/PROF/jmj.html   
Hongo Bunkyo-Ku, Tokyo 113, JAPAN

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

[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

[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

[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

[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

[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 + Ada dispatching

[Jon S Anthony]

In article <55cl9q$59m@tjnews.is.s.u-tokyo.ac.jp> jezequel@piccolo.is.s.u-tokyo.ac.jp (Jean-Marc Jezequel) writes:

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

> What do you mean? Conceptually it *is* (can be though of as) a
> field of the object (if I gather well what you mean by field). That
> it uses to not be at runtime is a compiler optimization. Or do you
> mean something else?

In languages like Eiffel, Sather, C++, etc. it is not a compiler
optimization.  That the operation is not part of the object is part of
the semantics of the language.  You cannot change this operation on a
per object basis.  Now, you can say that Joe Programmer can think this
way (that the operation is part of the object), but that just means he
doesn't understand the language.


> >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.
> 
>
> The problem is much more profound, because if you have single
> dispatch only, it *is* "special" somehow, whatever the syntax you
> use to write it.

No it is not.  The object does not contain the operation.  The
language semantics do not allow this interpretation.  You can pretend
that it does, but it doesn't.  You are not actually sending a message
to set_a.  Now, if we were talking about a _delegation_ based
language, then you would definitely have a point.

There is nothing special about set_a from set_b.  They are both of the
same class.  Both have the exact same operation Union.  Hmmm, unless
you are thinking of the case where set_b and set_a are _not_ in the
same class.  While this can happen in Eiffel, it can't happen in Ada,
so maybe this is where the problem is.


> For binary operations, it seems that there is no other way that
> double-dispatch (built in as in CLOS, or emulated as everywhere
> else).  Check e.g. the recent article "On Binary Methods" by Bruce,
> Cardelli et al. in Theory and Practice of Object System. Static

Are you saying that only multi-dispatch semantics allow "proper"
binary operations?  If so, why???  Also, note that in CLOS with the
two operands of the same type, the effective method will simply be
what Ada does anyway - select their single operation and perform it.
It's just that in CLOS you aren't restricted to _only_ this outcome.


> binding of one of the paramater poses problem, and in this respect
> Ada95 does not bring anything new (and in this respect is no better
> than C++/Java/Eiffel/Sather etc.).

I'm not sure I understand you here.  Ada does not statically bind one
parameter and not the other.  That is illegal.  Either all the
controlling parameters are dynamic or they are all static.  In either
case they have to be of the same type.


> Prove me wrong, please, and win a paper in TPOS.  But please, do not
> quote me outside of the context this time.

I'm not sure what the question or assertion even _is_, much less
whether you are wrong or not.


> of Current and Other ...  but unless you redispatch on the dynamic
> type of 'other', it does not solve the problem.

What problem?


> >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
> 
> I have trouble understanding these sentences. Could you please reformulate
> in English or even American English?

Yes, on reading them, the sentences have some typos.  Oh well.


> >   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.
> 
> Well, I still cannot see what it buys you beyond being able to
> choose at *compile time* (i.e. statically) the position of the
> parameter that receives the dispatch

It is a kind of (very) simple multi-dispatch.  Sort of.  The function
call will dispatch to the proper operation _based on_ the dynamic tags
of the other parameters and then the "outer" operation (the one with
the function as one of its parameters) will dispatch.

It is indeed, very constrained and not something to get wildly excited
about, but it is neat and useful.


> (big deal, IMHO) ? Or do you mean something else?  In that case,
> please give us a more complete example. Or would a real Ada95 expert
> tell us? (Yvon, are you still there?)

My my, we are getting nasty now, aren't we?  The examples I gave above
(as I indicated) came from Bob Duff - co-designer of Ada95.  I'm not
sure why you don't understand the examples - they are pretty straight
forward.


> >Well, sort of...  Seems like pretty extraneous futzing to accomplish
> >such a simple and ordinary thing.
> 
> Dealing with binary methods whose both arguments can be instances
> of subtypes of the declared types is *not* a "simple and ordinary
> thing". Again, if you have such a simple solution, tell us! I'll
> praise you then.

Well, now we see the problem.  As has been stated several times, the
subtypes must be _the same_ and are checked dynamically (in a
dispatching case) and statically (in a compile time case) for this.
You are thinking (as in Eiffel) of _dispatching_ operations which can
take _variants_ of the types.  In Ada, only operations of class-wide
types can take such variants at runtime and they are not dispatching -
completely statically bound at compile time.  They can just take any
instance of any type covered by their class-wide parameters.

Here's a case of someone who only sees one way of looking at things,
doesn't understand the other model, and then says it can't be done
because he is thinking solely in terms of the model where it is "*not*
a simple and ordinary thing".  Shrug.


> >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.
> 
> How can you say that?

Easy.

> I agree that they are quite commonplace in
> math-related software (linear algebra, sets etc.), and could
> sometimes appear in other pieces,

Exactly.

> but not to the point of being ubiquitous.

No one said they were.

> But that's not the point. Well, what is your point anyway?

Just that - depends on the area.  What's your point?  I mean, you sort
of got my point.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

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

[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

[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

[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

[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 + Ada dispatching

[Vincent WEBER]

In article <E00t53.CG2@syd.csa.com.au>, donh@syd.csa.com.au says...

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

Hum... I'm lost, two ada specialists saying two different things :) Let me cote 
an article from the french magazine "L'Objet" (Vol 1, no 1, Spring 95), by 
Antoine Bertier (Tomson Software Products) and Pascal Plisson (Alsys). I tried 
to translate from french to english, please apologize the mistakes if any :)

"It is important to note than tags of all the parameters have to be identical 
at run-time to have the dispatching done to only one effective operation. 
Therefore there is no priviliged parameter for dispatching as it is the case in 
other languages. This is an important advantage of Ada 95 's model compared to 
other languages such as C++, that break the natural symetry of some operations 
in privileging the parameter used for the dispatching ( et need a way to 
reference this parameter : "this" in C++). For instance :
  
  type TILABLE_WINDOW is new WINDOW;
  TILE(A,B : TILABLE_WINDOW);
    -- display the two window one under the other
    -- in covering all the screen
  MAIN_WINDOW, MESSAGE_WINDOW : TILABLE_WINDOW;
  TILE(MAIN_WINDOW, MESSAGE_WINDOW);
    -- the call is perfectly symetric. the parameters can be swapped
    -- in C++ we would have had a dissymetric call like:
    -- MAIN_WINDOW.TILE(MESSAGE_WINDOW);

  " (end of quotation).

Well I think that one of the two parts is wrong :) any comment ?

Re: Eiffel and Java + Ada dispatching

[Jean-Marc Jezequel]

In article <5563vp$1of@buggy.news.easynet.net>, Sacha@easynet.fr (Vincent WEBER) writes:
>In article <E00t53.CG2@syd.csa.com.au>, donh@syd.csa.com.au says...


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

>Hum... I'm lost, two ada specialists saying two different things :) Let me cote 
>an article from the french magazine "L'Objet" (Vol 1, no 1, Spring 95), by 

>  type TILABLE_WINDOW is new WINDOW;
>  TILE(A,B : TILABLE_WINDOW);
>    -- display the two window one under the other
>    -- in covering all the screen
>  MAIN_WINDOW, MESSAGE_WINDOW : TILABLE_WINDOW;
>  TILE(MAIN_WINDOW, MESSAGE_WINDOW);
>    -- the call is perfectly symetric. the parameters can be swapped
>    -- in C++ we would have had a dissymetric call like:
>    -- MAIN_WINDOW.TILE(MESSAGE_WINDOW);

>Well I think that one of the two parts is wrong :) any comment ?

No. Both are (seems to be, cause the Ada95 fragment lacks details) right.

1) Ada95 is still single dispatched
2) but this is combined with the static overloading inherited from Ada83; which is merely
syntactic sugar for routine having (statically) different signatures. In this respect, it is
exactly like C++ or Java, but for the symetric syntax. 
May be the confusion comes form the fact that in CLOS, this symetric syntax is used for
the real thing: multiple dispatch.


The only thing you really need to make use of OO polymorphism is dynamic binding.
While having at the same time static overloading can make some code fragment more "natural" to
write, the apparent proximity of this feature with dynamic binding yield so much confusion on
the non-expert eyes that you do not wonder why I prefer to teach Eiffel rather 
than C++, Java or even Ada95.


As an aside, I once wrote a paper on how to emulate multiple dispatch in a parallel 
linear algebra library in Eiffel, and it was refused on the ground that a well known 
existing library had already solved the problem using C++ overloading. Even this
"expert" C++ referee had no clue on the difference between static and dynamic binding :-(




---
Jean-Marc Jezequel               | Tel : +81 (3) 3812-2111 ext. 4116
IRISA/CNRS, currently visiting:  | Fax : +81 (3) 5689-4365
Dept. of Information Science     | e-mail : jezequel@irisa.fr  or
Faculty of Science               | e-mail : jezequel@is.s.u-tokyo.ac.jp
The University of Tokyo          | http://www.irisa.fr/pampa/PROF/jmj.html   
Hongo Bunkyo-Ku, Tokyo 113, JAPAN

Re: Eiffel and Java + Ada dispatching

[Joachim Durchholz]

donh@syd.csa.com.au wrote 01.11.96:

> Good point. Is this the (only) reason Eiffel does not have overloading?
> I remember thinking once that it would also complicate multiple inheritance
> but don't recall why I thought that.

Maybe because the 'rename' clause would not only have to list the original  
name, but the original signature as well?

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 + Ada dispatching

[Don Harrison]

Jean-Marc Jezequel writes:

:The only thing you really need to make use of OO polymorphism is dynamic binding.
:While having at the same time static overloading can make some code fragment more "natural" to
:write, the apparent proximity of this feature with dynamic binding yield so much confusion on
:the non-expert eyes ...

Good point. Is this the (only) reason Eiffel does not have overloading?
I remember thinking once that it would also complicate multiple inheritance but
don't recall why I thought that.

:As an aside, I once wrote a paper on how to emulate multiple dispatch in a parallel 
:linear algebra library in Eiffel, and it was refused on the ground that a well known 
:existing library had already solved the problem using C++ overloading. Even this
:"expert" C++ referee had no clue on the difference between static and dynamic binding :-(

Well, if it's been done in C++, then what more can you have to offer? :)

This reminds me of the Australian mathematician, Andrew? Prentice, who has 
trouble getting his papers on the origin of the Solar System published because 
he rejects the 'accepted wisdom' of established academia. The fact that many 
(all?) of his predictions about the outer planets have been confirmed by space 
probes doesn't seem significant to the assessors. He has found some friends in
applied astronomy (at the Jet Propulsion Laboratory), but theoreticians have 
largely snubbed him.



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

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Vincent WEBER writes:

:In article <E00t53.CG2@syd.csa.com.au>, donh@syd.csa.com.au says...
:
:>
:>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.  
:>
:
:Hum... I'm lost, two ada specialists saying two different things :) 

Sorry, I don't qualify as an Ada specialist (and comp.lang.ada will back me
up here). :)  However, ...

:Let me cote 
:an article from the french magazine "L'Objet" (Vol 1, no 1, Spring 95), by 
:Antoine Bertier (Tomson Software Products) and Pascal Plisson (Alsys). I tried 
:to translate from french to english, please apologize the mistakes if any :)

Don't know how the French was, but the English is pretty good. :)

:"It is important to note than tags of all the parameters have to be identical 
:at run-time to have the dispatching done to only one effective operation. 

Notice he's (you're) saying "only one effective effective operation" 
(single dispatching). What I didn't mention is that in Ada, control over
dispatching can be *shared* by multiple parameters, but for a call to be valid
the actual dispatching parameters must have the same type ensuring that
binding to a unique procedure occurs. In the example below, type TILABLE_WINDOW 
is presumably tagged so both parameters A and B jointly control dispatching. 
However, MAIN_WINDOW and MESSAGE_WINDOW must have the same type; otherwise, an exception is raised).

It almost appears that having B as a dispatching parameter is redundant 
but it conveys the extra information that it must have the same type as A.

:Therefore there is no priviliged parameter for dispatching as it is the case in 
:other languages. This is an important advantage of Ada 95 's model compared to 
:other languages such as C++, that break the natural symetry of some operations 
:in privileging the parameter used for the dispatching ( et need a way to 
:reference this parameter : "this" in C++). For instance :
:  
:  type TILABLE_WINDOW is new WINDOW;
:  TILE(A,B : TILABLE_WINDOW);
:    -- display the two window one under the other
:    -- in covering all the screen
:  MAIN_WINDOW, MESSAGE_WINDOW : TILABLE_WINDOW;
:  TILE(MAIN_WINDOW, MESSAGE_WINDOW);
:    -- the call is perfectly symetric. the parameters can be swapped
:    -- in C++ we would have had a dissymetric call like:
:    -- MAIN_WINDOW.TILE(MESSAGE_WINDOW);
:
:  " (end of quotation).

A symmetrical solution in Eiffel which also conveys the fact that the windows
must have the same type might be:

class TILABLE_WINDOW is ...
class TILABLE_WINDOW_OPS is
  ...
  tile (a, b: TILABLE_WINDOW) is 
  require same_type (a, b)
  do ... end
  ...
end

and somewhere:

  main_window, message_window : TILABLE_WINDOW
  window_ops: TILABLE_WINDOW_OPS
  ...
  window_ops.tile (main_window, message_window)

We've had to invent another class to get symmetry. Oh, well at least it's 
obvious we are using single-dispatching.


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

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

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

> Sorry, I don't qualify as an Ada specialist (and comp.lang.ada will back me
> up here). :)  However, ...

:-)


> Notice he's (you're) saying "only one effective effective operation"
> (single dispatching). What I didn't mention is that in Ada, control
> over dispatching can be *shared* by multiple parameters, but for a
> call to be valid the actual dispatching parameters must have the
> same type ensuring that binding to a unique procedure occurs.

Right.


> It almost appears that having B as a dispatching parameter is redundant 
> but it conveys the extra information that it must have the same type as A.

Right.


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

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 + Ada dispatching

[Jon S Anthony]

In article <5563vp$1of@buggy.news.easynet.net> Sacha@easynet.fr (Vincent WEBER) writes:

> In article <E00t53.CG2@syd.csa.com.au>, donh@syd.csa.com.au says...
> 
> >
> >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.  
> >
>
> Hum... I'm lost, two ada specialists saying two different things :)

Well, the problem is that Don is not an "ada specialist" and is in
error about there not being any semantics to this (or maybe just
simplifying to avoid the details).  There are indeed semantic aspects
as I point out in another note, but these do not imply multiple
dispatch.  So, that part is certainly correct.


> Let me cote an article from the french magazine "L'Objet" (Vol 1, no
> 1, Spring 95), by Antoine Bertier (Tomson Software Products) and
> Pascal Plisson (Alsys). I tried to translate from french to english,
> please apologize the mistakes if any :) "It is important to note
> than tags of all the parameters have to be identical at run-time to
> have the dispatching done to only one effective operation.
> Therefore there is no priviliged parameter for dispatching as it is
> the case in other languages. This is an important advantage of Ada
> 95 's model compared to other languages such as C++, that break the
> natural symetry of some operations in privileging the parameter used
> for the dispatching ( et need a way to reference this parameter :
> "this" in C++). For instance :

Yes, this is true and captures some (I suppose most) of the semantic
aspects.  But note that there is no conflict here with the assertion
that these are _not_ multi-dispatch.


> Well I think that one of the two parts is wrong :) any comment ?

Don's statement at face value is in error, but not on the salient part
of multiple-dispatch.


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

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Jon S Anthony writes:

:Well, the problem is that Don is not an "ada specialist" and is in
:error about there not being any semantics to this (or maybe just
:simplifying to avoid the details).  

It's plain that I simplified to help Vincent understand. It's better to present
the usual case and then deal with exceptional cases later if, and when, necessary.
I dealt with the exceptional case when it Vincent showed that he was confused by
the case of multiple dispatching parameters. 

It was also plain from my response that I *do* understand the semantics. 

I don't know why you claim I was in error except perhaps to portray me as a 
fool. If so, I won't waste time discussing anything with you.

:Don's statement at face value is in error, but not on the salient part
:of multiple-dispatch.

I've already explained this is not true.

BTW, the "Real OO" thread was in the early months of this year (February-ish 
to May-ish 1996) - Northern hemisphere Spring, Southern hemishpere Autumn. 
Call Autumn 'Fall' if you wish. (People living near the Equator will know what 
you mean even though they have evergreen rather than deciduous trees).


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

C to Ada

[Ali Mirhosseini]

Dear Fellows:

I am looking for a C to Ada translator, could you let me know of any
pulic domain software for Unix and Dos,

Cheers



Ali Reza Mirhosseini

------------------------------------------------------------------------
Laboratory for Imaging Science and Engineering	   Phone: +61 2 9351 4824
Department of Electrical Engineering		   Fax:   +61 2 9351 3847
University of Sydney, Sydney, NSW 2006		   Email: armir@ee.usyd.edu.au

WWW: http://cassius.ee.usyd.edu.au/~armir
-----------------------------------------------------------------------

Re: C to Ada

[Matthew Daniel]

Ali Mirhosseini wrote:
> 
> Dear Fellows:
> 
> I am looking for a C to Ada translator, could you let me know of any
> pulic domain software for Unix and Dos,
> 
> Cheers
> 
> Ali Reza Mirhosseini
> 
> ------------------------------------------------------------------------
> Laboratory for Imaging Science and Engineering     Phone: +61 2 9351 4824
> Department of Electrical Engineering               Fax:   +61 2 9351 3847
> University of Sydney, Sydney, NSW 2006             Email: armir@ee.usyd.edu.au
> 
> WWW: http://cassius.ee.usyd.edu.au/~armir
> -----------------------------------------------------------------------

look at 

http://www.adahome.com/

there is a tools and components link follow this to get a copy of c2ada, only for unix or the
like

Matt

Re: C to Ada

[Robert Dewar]

"I am looking for a C to Ada translator, could you let me know of any
pulic domain software for Unix and Dos,
"


Probably the only such software is implemented using zillions of neurons
and walking around in computers called Bob, or Fred, or Nancy. And likely
they are not in the public domain anyway.

Seriously, automatic translatoin of this kind is a recipe for creating
junk, and is almost never justifiable. If there is a reason for 
translating code, then there is a reason for re-engineering it. Perhaps
you can give some insight as to what problem you are trying to solve,
rather than ask about details on inappropriate solutions.

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

In article <E0BrFs.4st@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> It's plain that I simplified to help Vincent understand. It's better
> to present the usual case and then deal with exceptional cases later
> if, and when, necessary.  I dealt with the exceptional case when it
> Vincent showed that he was confused by the case of multiple
> dispatching parameters.

Check.


> It was also plain from my response that I *do* understand the semantics. 

Yes, I do agree from some of your other posts (especially the one about
"covariant" stuff) that you do understand the semantics.


> I don't know why you claim I was in error except perhaps to portray
> me as a fool. If so, I won't waste time discussing anything with
> you.

Nope.  Merely that in this particular note you only mentioned the
syntax aspects as being all there is.  This isn't (strictly speaking)
all there is and so was in error.  But, as you say you were just
avoiding the details.

While it is true that early in the "Real OO" thread I thought you were
a simple troller (for some very good reasons which we need not bring
up) I definitely changed my mind about this.  In fact, I have come to
see you as clearly contributing worth while stuff to the net.  One of
the few...

/Jon

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

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Jon S Anthony wrote (privately):

:News is clearly running behind and the note of my you were replying to
:below was before I saw a few of your other posts which clearly show
:you understand this stuff afterall.  Mea Culpa.  Guilty twit.  Grade A
:stupid.  Whatever else you want to call me. ;-)

Grovelling apology accepted but I would have more respect for you if it
were as public as your allegation.

and publicly:

:While it is true that early in the "Real OO" thread I thought you were
:a simple troller (for some very good reasons which we need not bring
:up) I definitely changed my mind about this.  In fact, I have come to
:see you as clearly contributing worth while stuff to the net.  One of
:the few...

Well, the stuff that's not founded in ignorance, at least. :( 

BTW, I'm done with throwing rocks at other people's languages. It's not helpful
to criticise other people's efforts. In the case of Ada, I have a better
appreciation of why it was designed the way it was and think the Ada95 designers
were faced with a difficult task in having as their starting point an existing 
language which supported a different paridigm. If Ada were designed from scratch
today, it would look quite different, IMO.



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

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

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

> Jon S Anthony wrote (privately):
> 
> :News is clearly running behind and the note of my you were replying to
> :below was before I saw a few of your other posts which clearly show
> :you understand this stuff afterall.  Mea Culpa.  Guilty twit.  Grade A
> :stupid.  Whatever else you want to call me. ;-)
> 
> Grovelling apology accepted but I would have more respect for you if it
> were as public as your allegation.

This is not a "grovelling apology" - it is simply accurate.  I'm not sure
what you mean about "public allegation"??  Shrug.  There was no allegation
anywhere (that I can tell anyway).

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

Re: Eiffel and Java + Ada dispatching

[Robert I. Eachus]

In article <557ce3$ojh@tjnews.is.s.u-tokyo.ac.jp> jezequel@piccolo.is.s.u-tokyo.ac.jp (Jean-Marc Jezequel) writes:

  > The only thing you really need to make use of OO polymorphism is
  > dynamic binding.  While having at the same time static overloading
  > can make some code fragment more "natural" to write, the apparent
  > proximity of this feature with dynamic binding yield so much
  > confusion on the non-expert eyes that you do not wonder why I
  > prefer to teach Eiffel rather than C++, Java or even Ada95.

   But you just teach it like we have always taught Ada
overloading--if the compiler is happy you don't have a problem. ;-)

   Seriously the combination of dispatching on multiple parameters in
Ada and overloading allows some really neat stuff--but the "simple"
examples are so nasty I'm not going to write them, lest someone copy
without understanding.  Basically if a subprogram has multiple
parameters which it dispatches on, and this can include the return
value, and there is one and only one way to interpret the expression
containing the call, then the dispatching resolves to a single
controlling type.

    If you want the effect of dispatching on multiple parameters, and
this is sometimes useful, you have to break the symmetry in your
declarations:

    function "+"(L: Object; R: Object'CLASS) return Object'CLASS;

    will dispatch only on the first parameter, and you may have a
second dispatching call to complete the dispatch.  (It is the nature
of these completing calls that they should be declared as generics
immediately in the scope containing the type declaration, and
instantiated elsewhere if they need both parameters.) Yes, you can
end up doing N**2 or even N**3 instantiations if the implementation of
the operation requires it.  But that is still a win, since you would
have had to write the individual operations anyway, but the generic
can do part of the work.

    The other case, which is much more useful is where you can use a
single intermediate type.  Now you end up with at most 2N or 3N
functions to write, and often using inheritance to eliminate most of
those.  For example suppose you have a tagged type, and you want to
define heterogenous list type over the class.  No problem, and no
generics or additional declarations required, including for the
operation:

    function "+"(L: Element, R: Element'CLASS) return Element_List;

    The body is:

    function "+"(L: Element, R: Element'CLASS) return Element_List is
    begin return L+New_List(R); end "+";
    
    This body has two dispatching operations.  New_List dispatches on
R, and the + dispatches to the + defined for L's type and List. No
overriding or additional declarations required, since the List type
acts as an intermediate.

    (You can do the same thing with method notation, but it is a lot
harder to get right.  Try it. ;-)
--

					Robert I. Eachus

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

Re: Eiffel and Java + Ada dispatching

[Joachim Durchholz]

jsa@alexandria wrote 31.10.96:

> I guess you like system validity problems.

No, Eiffel fanatics don't like system validity either (too complicated,  
difficult to ascertain correctness of checking code). In fact, there  
doesn't seem to be a compiler in existence that can do this check at  
compile-time.

Current technology seems to do the checks at run-time, which isn't worse  
than anything used to solve similar problems in other languages (typecasts  
in C++ especially if typesafe, typecase constructs and similar stuff).

*However*, there is a proposal floating around that allows static type  
checking without having to resort to system-wide checks, and this is  
commonly regarded as an advance over system validity and run-time checks.

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 + Ada dispatching

[Jon S Anthony]

In article <557ce3$ojh@tjnews.is.s.u-tokyo.ac.jp> jezequel@piccolo.is.s.u-tokyo.ac.jp (Jean-Marc Jezequel) writes:

> 2) but this is combined with the static overloading inherited from
> Ada83; which is merely syntactic sugar for routine having
> (statically) different signatures.

Criminey!  This is wrong too.  It is not "merely syntactic sugar", as it
is part and parcel of why Ada does not need any system validity checks!


> In this respect, it is exactly like C++ or Java, but for the
> symetric syntax.

This isn't correct either.  There are some other semantic aspects
floating around that make it different from C++/Java in this area.


> May be the confusion comes form the fact that in CLOS, this symetric
> syntax is used for the real thing: multiple dispatch.

Well, you got this right at any rate...


> The only thing you really need to make use of OO polymorphism is
> dynamic binding.  While having at the same time static overloading
> can make some code fragment more "natural" to write, the apparent
> proximity of this feature with dynamic binding yield so much
> confusion on the non-expert eyes that you do not wonder why I prefer
> to teach Eiffel rather than C++, Java or even Ada95.

I guess you like system validity problems.


> As an aside, I once wrote a paper on how to emulate multiple
> dispatch in a parallel linear algebra library in Eiffel, and it was
> refused on the ground that a well known existing library had already
> solved the problem using C++ overloading. Even this "expert" C++
> referee had no clue on the difference between static and dynamic
> binding :-(

I am having a bit of the same suspicion here...

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

Re: Eiffel and Java + Ada dispatching

[Jean-Marc Jezequel]

In article <JSA.96Oct30213354@alexandria>, jsa@alexandria (Jon S Anthony) writes:
>In article <557ce3$ojh@tjnews.is.s.u-tokyo.ac.jp> jezequel@piccolo.is.s.u-tokyo.ac.jp (Jean-Marc Jezequel) writes:
>
>> 2) but this is combined with the static overloading inherited from
>> Ada83; which is merely syntactic sugar for routine having
>> (statically) different signatures.
>
>Criminey!  This is wrong too.  It is not "merely syntactic sugar", as it
>is part and parcel of why Ada does not need any system validity checks!

I do not claim to be any expert in Ada95: actually I practiced Ada83 only.
So I might be wrong. In that case I would admit it without problem.
But you cannot simply say: you are wrong and stay at this level of generality.
What has "static overloading" to do with "system validity checks" ?
If it is not syntactic sugar, please tell us what it is. Or if you're lazy,
give a pointer to a relevant section of the reference manual, or to another easily
accessible litterature.

>> In this respect, it is exactly like C++ or Java, but for the
>> symetric syntax.
>
>This isn't correct either.  There are some other semantic aspects
>floating around that make it different from C++/Java in this area.

I didn't say (god forbid!) that Ada95 was anywhere the same as C++/Java!
I was limiting the scope of my comment to the ability
of having both *overloading* and *single dispatch*. 
Do you find it funny to cut one's statements at strategic points to distort
their meaning, or what? Sorry, but I still believe in good faith discussions.
And this has not to degenerate in a language war: Ada and Eiffel deserve better than that.

My only point in this post was that mixing *overloading* (a static mechanism AFAIK)
with *single dispatch* dynamic binding, using the same syntax for the call, was
making things a bit confusing for the user of the language. Since this is a
subjective point, I have no problem with you not agreeing with me. But I expect
real arguments on your side to be able to explain it myself to others.

The rest of your post is thus a bit off-topic:

>> The only thing you really need to make use of OO polymorphism is
>> dynamic binding.  While having at the same time static overloading
>> can make some code fragment more "natural" to write, the apparent
>> proximity of this feature with dynamic binding yield so much
>> confusion on the non-expert eyes that you do not wonder why I prefer
>> to teach Eiffel rather than C++, Java or even Ada95.
>
>I guess you like system validity problems.

System validity is not a problem in Eiffel from the theoritical point of view (at least
when only close systems are considered). Anyway, what is *your* problem with
system validity checks? Have you written real, usefull Eiffel code that bite you lately?
I'd be curious to know...

But I do not claim Eiffel is perfect (can you claim Ada95 is?).
And yes, system validity is one of the weak points.

---
Jean-Marc Jezequel               | Tel : +81 (3) 3812-2111 ext. 4116
IRISA/CNRS, currently visiting:  | Fax : +81 (3) 5689-4365
Dept. of Information Science     | e-mail : jezequel@irisa.fr  or
Faculty of Science               | e-mail : jezequel@is.s.u-tokyo.ac.jp
The University of Tokyo          | http://www.irisa.fr/pampa/PROF/jmj.html   
Hongo Bunkyo-Ku, Tokyo 113, JAPAN

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

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

> Jon S Anthony writes:
> 
> :> 2) but this is combined with the static overloading inherited from
> :> Ada83; which is merely syntactic sugar for routine having
> :> (statically) different signatures.
> :
> :Criminey!  This is wrong too.  It is not "merely syntactic sugar", as it
> :is part and parcel of why Ada does not need any system validity checks!
> 
> Disagree. Overloading *is* syntactic sugar because it merely allows reuse
> of an identifier without any semantic difference (to using a different one). 
> The reason Ada does not need checks on use of polymorphism is that 
> it is avariant (no variance) compared with Eiffel which is covariant.

Go back and re-read that long note I wrote in the "Real OO" thread on
why Ada does not have system validity problems and then the follow up
which tried to point out your misunderstandings and you will see why
you are wrong about this.  Well, I hope so - maybe you still don't get
get it.

The reason that OL enters into the puzzle is that it allows for the
definition of _new_ operations (on specific types) with descendent
controlling parameter(s) and a _non_ controlling descendent
parameter(s) but with the same name.  Now you can claim that this is
"confusing" (a value judgement), but that will most likely be because
you are not used to the differentiation between specific types and
class-wide types (which we went over in excrutiating detail...)

/Jon

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

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Jon S Anthony writes:

:In article <E06F2B.Az7@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
:
:> Jon S Anthony writes:
:> 
:> :> 2) but this is combined with the static overloading inherited from
:> :> Ada83; which is merely syntactic sugar for routine having
:> :> (statically) different signatures.
:> :
:> :Criminey!  This is wrong too.  It is not "merely syntactic sugar", as it
:> :is part and parcel of why Ada does not need any system validity checks!
:> 
:> Disagree. Overloading *is* syntactic sugar because it merely allows reuse
:> of an identifier without any semantic difference (to using a different one). 
:> The reason Ada does not need checks on use of polymorphism is that 
:> it is avariant (no variance) compared with Eiffel which is covariant.
:
:Go back and re-read that long note I wrote in the "Real OO" thread on
:why Ada does not have system validity problems and then the follow up
:which tried to point out your misunderstandings and you will see why
:you are wrong about this.

I was able to infer from your note why Ada you cannot break polymorhism.
(Broken polymorphism is the problem in Eiffel - System Validity it's solution).
The reason is that Ada is avariant - when overriding dispatching operations,
you cannot redefine non-dispatching parameters covariantly.

eg. Assuming type B descended from A and Q descended from P,

1.  procedure op (a: A; p: P'Class);     -- dispatches on a
    ...
2.  procedure op (b: B; p: P'Class);     -- dispatches on b (overriding op above)

But, as you point out below, a dispatching operation that has the same 
signature as another but a different non-dispatching parameter does not 
override the original, so cannot be called polymorphically wrt the original.

3.  procedure op (b: B; p: Q'Class);     -- dispatches on b (distinct operation from
                                         -- 1. above - does not override it).

What we can see from this is that overriding in Ada is implied (by the 
combination of descendant dispatching parameter, same non-dispatching parameter) 
rather than being explicit as in Eiffel (redefine clause).

:The reason that OL enters into the puzzle is that it allows for the
:definition of _new_ operations (on specific types) with descendent
:controlling parameter(s) and a _non_ controlling descendent
:parameter(s) but with the same name.  Now you can claim that this is
:"confusing" (a value judgement), but that will most likely be because
:you are not used to the differentiation between specific types and
:class-wide types ...

Yes. I agree this may be confusing to some. I was one of them. :) 
Personally, if writing Ada, I would prefer to use a different name rather 
than overloading the old one to remove all confusion.

4.  procedure new_op (b: B; p: Q'Class);   -- dispatches on b



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

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

In article <E0BKHr.3CC@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> I was able to infer from your note why Ada you cannot break
> polymorhism.  (Broken polymorphism is the problem in Eiffel - System
> Validity it's solution).  The reason is that Ada is avariant - when
> overriding dispatching operations, you cannot redefine
> non-dispatching parameters covariantly.

Right.  But part of the story for _how_ this is, is overloading.


> eg. Assuming type B descended from A and Q descended from P,
> 
> 1.  procedure op (a: A; p: P'Class);     -- dispatches on a
>     ...
> 2.  procedure op (b: B; p: P'Class);     -- dispatches on b (overriding op above)

Right.

>  But, as you point out below, a dispatching operation that has the
> same signature as another but a different non-dispatching parameter
> does not override the original, so cannot be called polymorphically
> wrt the original.

Right - it is an _overloading_ definition of the _specific_ types involved.


> 3.  procedure op (b: B; p: Q'Class); -- dispatches on b (distinct
>                                      -- operation from 1. above - does
>                                      -- not override it).

Right.


> What we can see from this is that overriding in Ada is implied (by
> the combination of descendant dispatching parameter, same
> non-dispatching parameter) rather than being explicit as in Eiffel
> (redefine clause).

Right (note that "parameter" for each sort may be plural).


> :The reason that OL enters into the puzzle is that it allows for the
> :definition of _new_ operations (on specific types) with descendent
> :controlling parameter(s) and a _non_ controlling descendent
> :parameter(s) but with the same name.  Now you can claim that this is
> :"confusing" (a value judgement), but that will most likely be because
> :you are not used to the differentiation between specific types and
> :class-wide types ...
> 
> Yes. I agree this may be confusing to some. I was one of them. :) 
> Personally, if writing Ada, I would prefer to use a different name rather 
> than overloading the old one to remove all confusion.

OK.  But then you lose some of the functionality.  Basically the OL
lets you have the "covariant" thingy, but forces you to supply the
exact definition for each possible such case.


> 4.  procedure new_op (b: B; p: Q'Class);   -- dispatches on b

Yes, but now this is not related to Op (in the sense I mention just
above).

/Jon

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

Re: Eiffel and Java + Ada dispatching

[Robert Dewar]

Don Harrison says

"Disagree. Overloading *is* syntactic sugar because it merely allows reuse
of an identifier without any semantic difference (to using a different one).
The reason Ada does not need checks on use of polymorphism is that
it is avariant (no variance) compared with Eiffel which is covariant."

You only disagree because you don't really know the details of what you
are talking about. You really need to know Ada 95 better before making
incorrect statements like this. In particular, overloading plays quite
an important role with respect to generic instantiation, and is much
more than syntactic sugar in Ada.

Re: Eiffel and Java + Ada dispatching

[Norman H. Cohen]

Robert Dewar wrote:

> You only disagree because you don't really know the details of what you
> are talking about. You really need to know Ada 95 better before making
> incorrect statements like this. 

I disagree.  Understanding Ada has never been a prerequisite for making
incorrect statements about it.  ;-)

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

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Robert Dewar writes:

:Don Harrison says
:
:"Disagree. Overloading *is* syntactic sugar because it merely allows reuse
:of an identifier without any semantic difference (to using a different one).
:The reason Ada does not need checks on use of polymorphism is that
:it is avariant (no variance) compared with Eiffel which is covariant."
:
:... In particular, overloading plays quite
:an important role with respect to generic instantiation, and is much
:more than syntactic sugar in Ada.

You appear to be referring to RM 12.3(14) under Generic Instantiation, Static
Semantics which says

  "The interpretation of each construct within a generic declaration or body
   is determined using the overloading rules ...".

Maybe I don't understand what this means but it's not clear how this is any 
different from other uses of overloading (in which there is no semantic 
difference from using unique procedure names). If you can provide an example 
showing there is such a difference, I'll believe you.


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

Re: Eiffel and Java + Ada dispatching

[Robb Nebbe]

On overloading:

you need to keep in mind that a language is a tool. People become very frusterated
with tools that interfere with doing work rather than help, unless they can
rationalize this in terms of saftey or something. Overloading is the language
getting out of your way so you can concentrate on what is really important.

Think of it as separation of concerns. When you are writing software it is better
to concentrate on finding meaningful names rather than "Did I already use that
somewhere?" I have better things to do than manually resolving overloading.

You are correct in saying that there is no semantic difference between
unique names and overloading. However, just because there is no semantic
difference don't suppose that it doesn't play a critical role in how the language
is defined. 

By the way, consider what Eiffel does. It determines which routine is to be called
based on the name of the routine and the type of one of the parameters. The only
difference with Ada is that Ada uses all the parameters. There is no semantic
difference between determining statically or dynamically which method is invoked.
When Eiffel compilers optimize away dispatching all they are really doing is
static overload resolution. 

Don Harrison wrote:
> 
> Robert Dewar writes:
> 
> :... In particular, overloading plays quite
> :an important role with respect to generic instantiation, and is much
> :more than syntactic sugar in Ada.
> 
> You appear to be referring to RM 12.3(14) under Generic Instantiation, Static
> Semantics which says
> 
>   "The interpretation of each construct within a generic declaration or body
>    is determined using the overloading rules ...".
> 
> Maybe I don't understand what this means but it's not clear how this is any
> different from other uses of overloading (in which there is no semantic
> difference from using unique procedure names). If you can provide an example
> showing there is such a difference, I'll believe you.

Re: Eiffel and Java + Ada dispatching

[Jean-Marc Jezequel]

In article <327F0D64.619A@iam.unibe.ch>, Robb Nebbe <nebbe@iam.unibe.ch> writes:
>On overloading:
>
>you need to keep in mind that a language is a tool. People become very frusterated
>with tools that interfere with doing work rather than help, unless they can
>rationalize this in terms of saftey or something. Overloading is the language
>getting out of your way so you can concentrate on what is really important.
>
>Think of it as separation of concerns. When you are writing software it is better
>to concentrate on finding meaningful names rather than "Did I already use that
>somewhere?" I have better things to do than manually resolving overloading.


Please let me use an example James Rogers sent me in a private mail:

type base_type is tagged record
   count : natural;
end record;

type derived_1 is new base_type with record
   Name : string(1..40);
end record;

type base_class_ptr is access all base_type'class;

Base_Obj : aliased base_type;
Derived_Obj : aliased derived_1;

Class_Ptr : base_class_ptr;

procedure print(Item : base_type);  -- (1)
procedure print(Item : derived_1);  -- (2)

-- Client side in Ada95

print(Base_Obj); -- static binding to (1)
print(base_type(Derived_Obj)); -- static binding to (1)
print(Derived_Obj);   -- static binding to (2)


-- Corresponding Client side in Eiffel (typical)

Base_Obj.print; --  binding to (1)
Derived_Obj.base_type_print; -- binding to (1)
Derived_Obj.print ;   --  binding to (2)


So usually finding a suitable name is not the problem when you lack overloading.
As for the preference on dotted or symetric syntax, someone already made the
point that it was no big deal.
And to be absolutely clear that this is not intented as an attack on Ada95, I claim
that I would be happy if I had to use Ada95 on a project (instead of say C++;-)

>You are correct in saying that there is no semantic difference between
>unique names and overloading. However, just because there is no semantic
>difference don't suppose that it doesn't play a critical role in how the language
>is defined. 

Yes, it does. For example by making things much more complicated;-)

>By the way, consider what Eiffel does. It determines which routine is to be called
>based on the name of the routine and the type of one of the parameters. The only
>difference with Ada is that Ada uses all the parameters. There is no semantic
>difference between determining statically or dynamically which method is invoked.

May be we have a different idea on the meaning of `semantics', but IMHO there is a 
difference. In one case it has to be done at compile time (and e.g. implemented using unique names as
you pointed out). In case of dynamic binding, it has (conceptualy) to be deferred until run-time,
and is basically implemented with a test on the object dynamic type (Ada tag?) to select
the right procedure.

In the head of the programmer, it makes a difference because she can assume that the most
"suitable" version of the procedure print will be called on x when she write x.print; 

Despite Ada95 being much more clear than C++ in this respect, in complex cases involving
both overloading and dynamic binding, it is still hardly possible to
explain in one short sentence (like above) the concept of what's going on.

My only point in this thread was that having both overloading (selecting the procedure at
compile time based on the static type of *all* the operands) and single distpatch (basically
selecting at runtime based on the dynamic type of one operand, plus minor Ada95 niceties) may
be confusing for some users. It's a matter of IMHO, so you won't need to agree with me.
BTW, I know it's not confusing for Ada95 experts (by definition;-)
But see the number of poeple who are still unsure whether Ada95 has multiple-dispatch a la CLOS,
or just an "augmented" single dispatch, e.g. the initiator of this thread.

Article Unavailable

Re: Eiffel and Java + Ada dispatching

[Robb Nebbe]

Jean-Marc Jezequel wrote:

> 
> May be we have a different idea on the meaning of `semantics', but IMHO 
> there is a difference. In one case it has to be done at compile time (and > e.g. implemented using unique names as you pointed out). In case of 
> dynamic binding, it has (conceptualy) to be deferred until run-time,and is 
> basically implemented with a test on the object dynamic type (Ada tag?) to 
> select the right procedure.

I'm using the the standard definition of semantics as it relates to the
meaning of a program. Semantics has to do with _what_ and NOT _when_; "when"
is closely related to "how" and is an implementation issue.

Do Eiffel compilers change the meaning of a program when they optimize away
a dispatching call? If not then it is not a semantic issue. I agree
completely that there is a difference but for me it is not related to the
semantics of the program.

>Robb Nebbe wrote:
> > When Eiffel compilers optimize away dispatching all they are really
> > doing is static overload resolution.

> I beg to differ. What they do is to determine statically that the 
> recipient of a call happends in a *given program* to be of exactly one 
> type. Since the runtime type test would then return a constant, they just 
> optimize out the test.

In Eiffel there are static and dynamic types where the static type is used
to type checking and the dynamic type for dispatching. In Ada there are
specific types and class-wide types. The relationship is as folows: A
dynamic type in Eiffel always corresponds to a specific-type in Ada. A
static type is either a specific type or a class-wide type. In some cases,
such as creation, it must be a specifc-type but most of the time it is
ambiguous and so in the absence of flow analysis it must be assumed to be a
class-wide type, which is the more general of the two cases.

Now there are two cases in Eiffel where you can optimize dispatching. The
first case is when you know that a static type is a specific type (for
exmple after creation). This means that you can optimize away the
dispatching because there will never be any need to dispatch in any program.
This is decidable locally in Eiffel. The second case is when you can
determine through analysis of the entire program that a static type is in
fact a specific-type then you can optimize away the dispatching because it
is never needed in that specific program. This is only decidable globally in
Eiffel.

In the first case the compiler can determine at compile time which routine
to call based on the name of the routine and the type (which is known to be
what Ada calls a specific type) of one of the "parameters" (the term is used
very loosely so use your imagination).

Can you see the analogy with overloading? I didn't mean to pretend that they
are precisely the same (which you would have been a reasonable
interpretation of my previous post :-) just that they are similar. Claiming
that Eiffel has no overloading, while technically correct, provides
virtually no insight into the relationship between Ada and Eiffel. I would
prefer that these discussions lead to a better understanding of this
relationship at some meaningful level.

Robb Nebbe

To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Don Harrison]

Robb Nebbe writes:

:you need to keep in mind that a language is a tool. People become very frusterated
:with tools that interfere with doing work rather than help, unless they can
:rationalize this in terms of saftey or something. Overloading is the language
:getting out of your way so you can concentrate on what is really important.

This may be true in some cases (eg. for Ada) but there is also a downside. 
(See below).

:Think of it as separation of concerns. When you are writing software it is better
:to concentrate on finding meaningful names rather than "Did I already use that
:somewhere?" I have better things to do than manually resolving overloading.

IMO, operations that do the same thing should have the same name and there
should be only one operation per class that does a particular thing. In 
particular, overriding operations should retain the same name (unless a more
specific name is in order due to specialisation). Further, if two operations 
do similar but different things, they should still be given distinct names. 
My justification for this is that it is easier to understand an operation call 
if you can disregard the type of the non-dispatching parameters. Having to
consider their type just makes understanding more difficult.

Excluding overloading is reasonable for Eiffel but may not be for Ada. The 
reason I say this is that Eiffel is covariant and Ada avariant. As Jon pointed 
out, you may wish to use overloading to indicate that a 'covariant' operation 
does the same thing. Because in Eiffel such operations are truly covariant,
they are semantically related to their parent operations (by inheriatance)
and share the same name. So, Eiffel does not need overloading (for this 
purpose, at least).

Another related problem I see with overloading is that it is too liberal in
that it permits you to use a common name for completely unrelated operations.
Overloading can encourage you to be lazy by using an existing name instead 
of thinking of a more appropriate one. IMO, this freedom to name poorly
promotes obfuscation. 

:You are correct in saying that there is no semantic difference between
:unique names and overloading. 

Okay.

:However, just because there is no semantic
:difference don't suppose that it doesn't play a critical role in how the language
:is defined. 

Not sure what you mean here.

:By the way, consider what Eiffel does. It determines which routine is to be called
:based on the name of the routine and the type of one of the parameters. The only
:difference with Ada is that Ada uses all the parameters. 

Only in a special case, though.

:There is no semantic
:difference between determining statically or dynamically which method is invoked.
:When Eiffel compilers optimize away dispatching all they are really doing is
:static overload resolution. 

Yes, but this complexity is *hidden* form the user (as it ought to be).


Yes, a language is just a tool but a good tool will give you help where you
need it and this may mean curtailing your freedom where it will do you good.
An absence of overloading is a help rather than a hinderance, IMO.


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

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Robb Nebbe]

To overload or not to overload is not the question IMO.
Overloading is a language mechanism that Ada has and Eiffel
doesn't; this is an apples and oranges problem. The real question
is how do languages figure out which method should be invoked.

Ignoring scoping rules we see that:

C uses just the name.

Eiffel uses the name and the type of one of the parameters.

Ada uses the name and the type of all the parameters.


C is broken. When you program in C you have to come up with naming
schemes to avoid identifier clashes. Eiffel and Ada work just
fine. If Eiffel truly used just the name and nothing more then not
only would every routine of every class have to have a different
name but polymorphism would be impossible. 

Languages are essentially sets of mechanisms. You seem to be
claiming that Ada has one mechanism and Eiffel doesn't when in
fact even though Eiffel doesn't have the same mechanism it does
have one that overlaps.

Robb

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Don Harrison]

Robb Nebbe writes:

:To overload or not to overload is not the question IMO.
:Overloading is a language mechanism that Ada has and Eiffel
:doesn't; this is an apples and oranges problem. The real question
:is how do languages figure out which method should be invoked.

Yes, a nice non-contentious topic of discussion is just that. Personally,
I'm more interested in what is the simplest binding mechanism a language
can provide which does everything you need and no more than you need.

:Ignoring scoping rules we see that:
:
:C uses just the name.
:
:Eiffel uses the name and the type of one of the parameters.
:
:Ada uses the name and the type of all the parameters.

Nice summary.

:C is broken. When you program in C you have to come up with naming
:schemes to avoid identifier clashes. 

We can always agree by throwing rocks at C. :)

:Eiffel and Ada work just
:fine. If Eiffel truly used just the name and nothing more then not
:only would every routine of every class have to have a different
:name but polymorphism would be impossible. 

Yes.

:Languages are essentially sets of mechanisms. You seem to be
:claiming that Ada has one mechanism and Eiffel doesn't when in
:fact even though Eiffel doesn't have the same mechanism it does
:have one that overlaps.

I think we're saying pretty much the same thing - that individual binding 
mechanisms should not be considered in isolation but in relation to each 
other. 

However, in relation to Eiffel, I'm saying that it has no *need* of an 
overloading mechanism because it is redundant due to the availability of 
covariance. An operation which you might choose to implement in Ada by 
overloading an inherited one (because they do the same job), you would 
implement in Eiffel as an overriding operation because it belongs in the 
same inheritance hierarchy (according to Eiffel's scheme of things).

[Before half the world disputes the latter part of this sentence, kindly note 
the qualifier in parentheses].

So, for Eiffel, rather than dynamic binding overlapping with overloading,
it obviates the need for it.


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

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Jon S Anthony]

In article <slrn5836sh.rl.schlegel@pella.informatik.uni-rostock.de> schlegel@pella.informatik.uni-rostock.de (Juergen Schlegelmilch) writes:

> In article <E0HKx9.8E3@syd.csa.com.au>, Don Harrison wrote:
> >
> >However, in relation to Eiffel, I'm saying that it has no *need* of an 
> >overloading mechanism because it is redundant due to the availability of 
> >covariance. An operation which you might choose to implement in Ada by 
> >overloading an inherited one (because they do the same job), you would 
> >implement in Eiffel as an overriding operation because it belongs in the 
> >same inheritance hierarchy (according to Eiffel's scheme of things).
> 
> Hm, being not too familiar with Ada, I may be wrong, but in the subclass
> you have both operations available, 

Correct.


> while with Eiffel's redefinition you only have the redefined but not
> the inherited (unless you inherited once, but then you have to
> rename). Thus, in a piece of code where an operation is applied to
> arguments suitable only for the inherited version, Eiffel will
> signal a type error (system validity or by runtime crash :-), while
> Ada will use the inherited (overloaded) version.

Correct.


> So, covariant redefinition is not a mechanism to implement/simulate
> overloading.

Interesting point.  The other way 'round though, does sound "right"...

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

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Juergen Schlegelmilch]

In article <E0HKx9.8E3@syd.csa.com.au>, Don Harrison wrote:
>
>However, in relation to Eiffel, I'm saying that it has no *need* of an 
>overloading mechanism because it is redundant due to the availability of 
>covariance. An operation which you might choose to implement in Ada by 
>overloading an inherited one (because they do the same job), you would 
>implement in Eiffel as an overriding operation because it belongs in the 
>same inheritance hierarchy (according to Eiffel's scheme of things).

Hm, being not too familiar with Ada, I may be wrong, but in the subclass
you have both operations available, while with Eiffel's redefinition you
only have the redefined but not the inherited (unless you inherited once,
but then you have to rename). Thus, in a piece of code where an operation 
is applied to arguments suitable only for the inherited version, Eiffel 
will signal a type error (system validity or by runtime crash :-), while Ada 
will use the inherited (overloaded) version.

So, covariant redefinition is not a mechanism to implement/simulate 
overloading.

  Juergen Schlegelmilch

-- 
+-----------------------------------------------------------------------------+
 Dipl.-Inf. Juergen Schlegelmilch                 University of Rostock
 email: schlegel@Informatik.Uni-Rostock.de        Computer Science Department
 http://www.informatik.uni-rostock.de/~schlegel   Database Research Group 
 Tel: ++49 381 498 3402                           18051 Rostock 
 Fax: ++49 381 498 3426                           Germany
+-----------------------------------------------------------------------------+

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Don Harrison]

I wrote:

:>However, in relation to Eiffel, I'm saying that it has no *need* of an 
:>overloading mechanism because it is redundant due to the availability of 
:>covariance. An operation which you might choose to implement in Ada by 
:>overloading an inherited one (because they do the same job), you would 
:>implement in Eiffel as an overriding operation because it belongs in the 
:>same inheritance hierarchy (according to Eiffel's scheme of things).

These comments are made in the context of the example Jon Anthony and I
discussed. The different schemes of Ada and Eiffel might be demonstrated 
by expanding the example Jon and I were discussing.

Assuming types A and B with heirs C and D repectively. Consider the following
operations:

Ada                                        Eiffel
---                                        ------

A's operations
op (a: A; b: B'Class)                (1)    In A: op (b: B)                  (4)

B's operations
op (c: C; d: D'Class)  -- overloaded (2)   In C: op (d: D)      -- overrided (5)
op (c: C; b: B'Class)  -- inherited  (3)   In C: new_op (b: B)  -- new       (6)

What we see is that Ada has taken the safe approach of diverting polymorphism
down the avariant path (3). The specialised op (2) becomes an overloaded 
operation and is no longer polymorphic wrt (1). Note that (3) is more general
than (2).

On the Eiffel side, polymorphism continues down the line of specialisation
(true covariance) so that (5) is polymorphic wrt (4). The more general (6)
is a new operation.

Now the contentious part. :(  The issue of which model is 'correct' depends on
which operation of B can better be regarded as functionally equivalent to 
the operation in A. (The safety issue is secondary, IMO - I'm talking about
modelling integrity). What seems to happen in the real world is that as
interactions between things become more specific, the things involved become
more specific as well (or some may stay the same). (The things do not become
*less* specific, but that is another matter). To model this faithfully,
you would need multiple dispatching but for most purposes, you can use use the
simpler (but lop-sided) model of single dispatching. But the important thing
is that we need to cater for the situation of both things becoming more
specific. If we don't, then what we end up with is specialisations that are
lop-sided and are capable of modelling only the special case where only one
thing becomes more specialised. (This is what happens in Ada).

I think the choice in Eiffel of making specialisations functionally equivalent
to their generalisations is the right one in terms of modelling integrity.
The downside is having then to deal with the non-trivial problem of breaking
polymorphism. :(  By comparison, the Ada model is completely safe, but it
sacrifices modelling integrity to acheive it, IMO.


Juergen Schlegelmilch wrote:

:Hm, being not too familiar with Ada, I may be wrong, but in the subclass
:you have both operations available, while with Eiffel's redefinition you
:only have the redefined but not the inherited (unless you inherited once,
                                                                     ^^^^
                                                                     twice?

:but then you have to rename). Thus, in a piece of code where an operation 
:is applied to arguments suitable only for the inherited version, Eiffel 
:will signal a type error (system validity or by runtime crash :-), 

IMO, this is what ought to happen because because the operation has become 
more specific and so requires more specific parameters. The parameter 
combination provided is invalid, so the runtime system (correctly) raises an 
exception. This highlights the fact that there is an error in the client which 
must be fixed. If a more general operation realy *is* required, then you can 
define a *new* operation [(6) in my example] for this purpose. So, Eiffel 
dispatches to a more specific operation by default rather than to a more general 
one. This differs from Ada which ...

: will use the inherited (overloaded) version.

So, Ada dispatches to a more general operation by default rather than to a 
more specific one. This is the wrong way round, IMO. I think calling a more 
general operation ought to be the exception rather than the default. Some will 
not agree with me but that's okay. :)

:So, covariant redefinition is not a mechanism to implement/simulate 
:overloading.

Just as well I didn't say that then. :)

I *am* saying that because Eiffel is covariant, you don't have to re-invent
an operation as an overloaded operation due to inheriting some unwanted 
baggage that no longer reflects the specialisation of an abstraction. 


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

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Don Harrison]

(A bit of explanation on my last post). I wrote:

:I think the choice in Eiffel of making specialisations functionally equivalent
:to their generalisations is the right one in terms of modelling integrity.

By 'functionally equivalent to', I mean 'polymorphic wrt'. 

The issue of modelling integrity implies a pragmatic consideration as well.
If specialisations reflect greater modelling integrity, you would also expect
that specialised operations are what you would want to *use* (call) most of the 
time rather than general ones. It makes sense, then (to maximise the power of
dynamic binding), for them to be polymorphic wrt the parent class. I don't
have any data to back this up but it seems logical. (if someone can confirm
this, please share it with us).

If it's true that specialisations *are* the operations you want most often,
then making the general (inherited) operations polymorphic means that dynamic
binding is wasted on a minority of calls.


I should also clarify the following.

: ... So, Eiffel 
: dispatches to a more specific operation by default rather than to a more general 
: one.

should read

... So, Eiffel 
dispatches to a more specific operation by default and does not inherit the
more general parent operation. However, if you *do* want the parent operation
as well, then you can repeatedly inherit it and leave one the same and 
specialise the other. This is where Eiffel is very flexible compared with Ada 
because you can nominate *either* the inherited (parent) operation *or* the 
specialised one to be polymorphic wrt the parent. 

and

: So, Ada dispatches to a more general operation by default rather than to a 
: more specific one. ... 

should read

So, Ada dispatches to the general (inherited) operation by default rather than 
to a more specific new one. ... 


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

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Jon S Anthony]

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

> If it's true that specialisations *are* the operations you want most
> often, then making the general (inherited) operations polymorphic
> means that dynamic binding is wasted on a minority of calls.

First, there is no evidence for this.  Second, the conclusion you draw
doesn't follow anyway.


> should read
> 
> ... So, Eiffel 
> dispatches to a more specific operation by default and does not
> inherit the more general parent operation. However, if you *do* want
> the parent operation as well, then you can repeatedly inherit it and
> leave one the same and specialise the other.

Yes, but that doesn't eliminate the type safety issues.


> This is where Eiffel is very flexible compared with Ada because you
> can nominate *either* the inherited (parent) operation *or* the
> specialised one to be polymorphic wrt the parent.

I don't know why you keep saying this sort of stuff.  You can do this
in Ada as well if that is what you _really_ want.  Just use a class
wide parameter for the non-controlling parameter.  Really, I don't see
the big deal here at all.

    ... Op ( x : P;  y : A'Class )...
...
    ... Op ( x : C;  y : B'Class )...
...
    i : P'Class := ... Something in P's type tree
    j : A'Class := ... Something in A's type tree

    ... Op(i, j) ... dispatch to either P's Op or C's op depending on
                     what sort of thing is in i.  Further, if j is NOT
                     a B thing, then raise constraint error


> should read
> 
> So, Ada dispatches to the general (inherited) operation by default
> rather than to a more specific new one. ...

Well, that's still wrong.  This "default" stuff is completely
irrelevant and has nothing to do with anything in the Ada context.


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

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Jon S Anthony]

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

> Now the contentious part. :( The issue of which model is 'correct'
> depends on which operation of B can better be regarded as
> functionally equivalent to the operation in A. (The safety issue is
> secondary, IMO - I'm talking about modelling integrity). What seems
> to happen in the real world is that as

The real world has nothing to do with it.  What is "modelling
integrity" anyway?


> interactions between things become more specific, the things
> involved become more specific as well (or some may stay the
> same). (The things do not become *less* specific, but that is
> another matter). To model this faithfully,

Things in the world aren't specific or general at all.  That is an
artificial organizational constraint applied in the semantics of some
modeling schemes (taxonomic...)  You really must separate the world
from the formalism or you will never get anywhere.


> :but then you have to rename). Thus, in a piece of code where an operation 
> :is applied to arguments suitable only for the inherited version, Eiffel 
> :will signal a type error (system validity or by runtime crash :-), 
> 
> IMO, this is what ought to happen because because the operation has become 
> more specific and so requires more specific parameters.

Well, in a covariant model.  But why think that is all there is or
even that it is the best????  There's just no evidence for it.


> must be fixed. If a more general operation realy *is* required, then
> you can define a *new* operation [(6) in my example] for this
> purpose. So, Eiffel dispatches to a more specific operation by
> default rather than to a more general one. This differs from Ada
> which ...
>
> : will use the inherited (overloaded) version.
>
> So, Ada dispatches to a more general operation by default rather
> than to a more specific one. This is the wrong way round, IMO. I

How did you arrive at that conclusion??  No, it simply dispatches to
the operation for which the arguments are intended.  If it is to the
more general, well then that is because the operands passed _are_ of
the more general type!


> think calling a more general operation ought to be the exception
> rather than the default. Some will not agree with me but that's
> okay. :)

Well, I disagree, because you are just plain factually wrong.


> I *am* saying that because Eiffel is covariant, you don't have to
> re-invent an operation as an overloaded operation due to inheriting
> some unwanted baggage that no longer reflects the specialisation of
> an abstraction.

No, you are not "re-inventing" anything.  You aren't overloading for
those reasons at all.  You overload because a) the inherited operation
is not refined in the "other" parameter and that is what you want and
b) using a different name for the operation is confusing, misleading,
and leads to poor software maintenance.  Which simply says, you can
have your cake (complete safety) and eat it too (give the programmer
model the functional equivalence of unbroken covariance).
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Jon S Anthony]

In article <E0HKx9.8E3@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Robb Nebbe writes:
> 
> :To overload or not to overload is not the question IMO.
> :Overloading is a language mechanism that Ada has and Eiffel
> :doesn't; this is an apples and oranges problem. The real question
> :is how do languages figure out which method should be invoked.
> 
> Yes, a nice non-contentious topic of discussion is just that. Personally,
> I'm more interested in what is the simplest binding mechanism a language
> can provide which does everything you need and no more than you need.

Unfortunately, that depends on what you mean by "simple".  While
Eiffel is simple in some aspects here (has only one construct), it is
complex in others (who understands "broken" polymorphism and the
attendant system validity issues?)  Ada is simple in some aspects (no
broken pm or worries about what it may mean, while letting you
basically do what you want in this context [refine on non controlling
parameters]) but more complex in that it has another construct:
overloading and this might fool you at times.

The whole thing boils down to tradeoffs, which in turn depend in large
measure on the overall context.


> However, in relation to Eiffel, I'm saying that it has no *need* of an 
> overloading mechanism because it is redundant due to the availability of 
> covariance.

True.  But it pays a non-trivial price for this.


> So, for Eiffel, rather than dynamic binding overlapping with overloading,
> it obviates the need for it.

I think the real problem here is that dynamic binding is not the same
category of thing as overloading and so comparing the two leads to
confusion.

/Jon

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

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Don Harrison]

Jon S Anthony writes:

:Unfortunately, that depends on what you mean by "simple".  

Yes, the concept is relative. :(

:I think the real problem here is that dynamic binding is not the same
:category of thing as overloading and so comparing the two leads to
:confusion.

Yes, and that seems to have happened. :)


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

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[bill.williams]

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

> However, in relation to Eiffel, I'm saying that it has no *need* of an 
> overloading mechanism because it is redundant due to the availability of 
> covariance. An operation which you might choose to implement in Ada by 
> overloading an inherited one (because they do the same job), you would 
> implement in Eiffel as an overriding operation because it belongs in the 
> same inheritance hierarchy (according to Eiffel's scheme of things).
> 
> [Before half the world disputes the latter part of this sentence, kindly note 
> the qualifier in parentheses].

Which set of parentheses, 1st or 2nd?

I'm not sure I understand what you're saying here. Can we try an
example so you can tell me that I've got the wrong end of the
proverbial stick? 

Suppose I write a complex number class (gosh, how original) and I
define all the normal arithmetic operators. In Ada I can overload
these operators to define 
  <complex> + <real> 
as well as 
  <complex> + <complex>
[I can do it in C++ as well, but we won't mention that...]
You seem to be suggesting that in Eiffel I need to define a class
which inherits from complex and defines interactions with reals. But
even this doesn't work. If I have a variable which is of the
complex class I can't add reals to it. If it's of the interaction
class, then I can't add complex's to it. The only solution Eiffel
offers me is to define 'add_complex' and 'add_real' members to the
complex class. While this achieves the functionality I need it falls
way short in terms of ease of maintenance when 'programming in the
large' IMO.

Sorry, you've prodded one of the bees in my bonnet w.r.t Eiffel and I
just couldn't let this one go by.

Cheers
Bill
-- 
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!

bill.williams@gecm.com
Tel: +44 1245 242016
Fax: +44 1245 242003

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Don Harrison]

Bill Williams writes:

:Which set of parentheses, 1st or 2nd?

2nd.

:I'm not sure I understand what you're saying here. Can we try an
:example so you can tell me that I've got the wrong end of the
:proverbial stick? 

I'll attempt to clarify what I'm saying. It is simply that Ada and Eiffel
offer different rules for selecting the polymorphic operation. The following 
table hopefully summarises the essential differences between the two schemes:

                           Ada                         Eiffel
--------------------------------------------------------------------------------

1) How selected?           Implicit                    Explicit

2) Which selected?         Same signature except for   Redefines clause (+ optional
                           dispatching parameter       select clause for repeated
                                                       inheritance)

3) Selection choice?       No                          Yes

4) Safe?                   Yes                         Yes (if supported by static
                                                       validity rules); No (if not)
5) Other operations        Yes (if has same name)      No (must have different name)
   overloaded?

In the case of Ada, any operation that happens to have the same name as the
polymorphic operation will happen to be overloaded. This has no effect on the 
semantics of polymorphism. I hope this clarifies the issue. If still unsure, 
re-read my post containing the example comparing Ada and Eiffel plus the addendum 
about repeated inheritance.

:Suppose I write a complex number class (gosh, how original) and I
:define all the normal arithmetic operators. In Ada I can overload
:these operators to define 
:  <complex> + <real> 
:as well as 
:  <complex> + <complex>
:[I can do it in C++ as well, but we won't mention that...]
:You seem to be suggesting that in Eiffel I need to define a class
:which inherits from complex and defines interactions with reals. 

Perish the thought. :)

:But even this doesn't work. If I have a variable which is of the
:complex class I can't add reals to it. If it's of the interaction
:class, then I can't add complex's to it. The only solution Eiffel
:offers me is to define 'add_complex' and 'add_real' members to the
:complex class. While this achieves the functionality I need it falls
:way short in terms of ease of maintenance when 'programming in the
:large' IMO.

This is basically what I have in mind except that 'add_complex' may just be
called 'add'. Something like:

  - Class NUMERIC contains an 'add' operation for NUMERICs
  - Class NUMERIC has heirs COMPLEX and REAL.

  - Class REAL redefines 'add' covariantly to add REALs

  - Class COMPLEX redefines 'add' covariantly to add COMPLEXes
  - Class COMPLEX defines an 'add_real' to add COMPLEX and REAL.

(Details omitted to protect the innocent).
  
:Sorry, you've prodded one of the bees in my bonnet w.r.t Eiffel and I
:just couldn't let this one go by.

Yes, I've noticed you have a few. :)


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

Re: To overload or not to overload (was Eiffel and Java + Ada dispatching)

[Norman H. Cohen]

Robb Nebbe wrote:

> Ignoring scoping rules we see that:
> 
> C uses just the name.
> 
> Eiffel uses the name and the type of one of the parameters.
> 
> Ada uses the name and the type of all the parameters.

Ada also distinguishes whether a call is a procedure call or a function
call and, in the case of a function call, considers the result type
expected in a given context.  Thus

   procedure P (X: in Integer; Y: out Float);
   function P (X: Integer; Y: Float) return Character;
   function P (X: Integer; Y: Float) return String;

can all be overloaded (which is not the case for the corresponding
declarations in C++ or Java). 

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

Re: Eiffel and Java + Ada dispatching

[Robert I. Eachus]

In article <55p0i3$2u4@tjnews.is.s.u-tokyo.ac.jp> jezequel@piccolo.is.s.u-tokyo.ac.jp (Jean-Marc Jezequel) writes:

  > Just to change the subject, does anyone know why the designers of
  > Ada95 did not choose to include the true multiple-dispatch a la
  > CLOS (or point to a reference on this)?  At leat the syntax have
  > been a problem; whereas it is in Java/C++/Eiffel.

    It was felt to be too much work for too little gain.  With the
current rules a programmer can provide a multiply dispatching routine,
and it is not that uncommon.  But there is a little extra work for the
implementor of the operation, but it is linear.  (In other words if
you have a routine:

     function Foo(X: Foob; Y: Foob'CLASS) return Boolean;

    That underneath calls:

     function Foobar(X: Foob'CLASS; Y: Foob; Additional: Parameters)
        return Boolean;

   Then simulating 'true' multiple dispatch may require overriding Foo
and Foobar for a new descendent of Foob, not just redefinition of Foo.
But the amount of work to be done, assuming you know what you are
doing is the same.

   For example, I created a heterogenous list class, and thought that
it would be nice to have the operation:

   function "&"(X,Y: Object'Class) return List;

   where X and Y can be of any type descended from Object.  The body
is REAL easy:

   function "&"(X,Y: Object'Class) return List is
   begin return Append(New_List(X),Y); end "&";

   Append and New_List are functions that are dispatching and may
require overriding, but as you can see, the "&" above dispatches on
both parameters, but doesn't require writing N squared operations for
N new subclasses.  In fact, it will usually be the case that no new
operations need to be writen or overridden when a new object type is
added to the list.  In more complex cases, the programmer may have
some work to do to figure out how to keep the implementation burden of
adding a new class under control, but in general you simply can't
manage the N-squared case and don't want to.

   (This is not to say that there aren't cases where you want to
implement boundary conditions with special values. For example a list
type that can contain other lists, but that I have never seen any case
where you want the general non-linear complexity.)

--

					Robert I. Eachus

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

Re: Eiffel and Java + Ada dispatching

[Joachim Durchholz]

nebbe@iam.unibe.ch wrote 05.11.96:

> By the way, consider what Eiffel does. It determines which routine is to be
> called based on the name of the routine and the type of one of the
> parameters. The only difference with Ada is that Ada uses all the
> parameters.

I don't think so. Overloading in Ada determines which routine to call _at_  
_compile_ _time_. This is very different from Eiffel, which uses the type  
of one of the parameters to determine which routine to call, _at_ _run_  
_time_ (this is called dynamic binding).

> There is no semantic difference between determining statically
> or dynamically which method is invoked. When Eiffel compilers optimize away
> dispatching all they are really doing is static overload resolution.

In a sense, you are right. In the absence of polymorphism, dynamic binding  
degenerates to overloading. (No downplay on overloading intended - I found  
it quite useful, though it also makes a great pistol if you don't control  
the semantics very carefully. Dynamic binding is an even better pistol,  
but luckily the programming-by-contract rules provide an effective safety  
catch.)

However, the central difference is that dynamic binding is always there in  
Eiffel. You don't have to rewrite Eiffel code to make overloading work,  
you just don't use polymorphism. You'd have to rewrite Ada code to go from  
overloading to dynamic binding.

The situation is a bit similar to multiplication optimization. Compilers  
can optimize multiplications with a power of two by issuing left-shift  
instructions instead of multiplications. But programming languages don't  
require the programmer to write all multiplications in terms of left-shift  
operators (even C compilers don't enforce this ;) ), and programmers  
usually don't think about the difference.
Overloading on the first routine parameter is a similar case for an Eiffel  
programmer; there is no reason why he should consider this special case as  
anything peculiar.

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 + Ada dispatching

[Robert I. Eachus]

   Okay... (This code is for demonstration purposes only...these
features are useful, but not often used with predefined types or small
generics.)

   generic
     with function "+"(L, R: Integer) return Integer is <>;
   procedure Test(X,Y: in Integer);
   
   
   with Text_IO;
   procedure Test(X,Y: in Integer) is 
   begin
     Text_IO.Put_Line(" The sum of" & Integer'IMAGE(X) & " and" &
               Integer'IMAGE(Y) & " is" & Integer'IMAGE(X+Y) & ".");
   end Test;

   with Test;
   procedure Main is
     procedure Test1 is new Test;

     function "+"(L,R: Integer) return Integer
     is begin return L*R; end "+";

     procedure Test2 is new Test;
   
  begin 
    Test1(5, 10);
    Test2(5, 10);
  end Main;

spectre% main
 The sum of 5 and 10 is 15.
 The sum of 5 and 10 is 50.

     Notice that a much more normal situation would have the two
instantiations in non-overlapping scopes, and the operator definitions
coming from a package which defined some generic formal type.

     What this is showing is not that it is possible to maliciously
mess with definition of "+", but that the fact that parameter matching
for generic formal subprogram parameters uses overloading rules is
significant.  It is a very useful feature to be able to instantiate a
generic in a scope and inherit the local statically enclosing
definitions of certain operations.  It is even more useful that the
operations are selected based on the name of the function AND the
parameter and return value profile.  You not only get the local
operator, you get the right version to match the other generic
formals.

     (Note that to get the local definitions of predefined operators
for types, generic formal and otherwise, you need to explicitly
declare those operators as generic formal subprograms.  But the at the
point of the instantiation, defaults allow the user to ignore these
"extra" formal parameters.)

     Now what does all this have to do with the no overloading model?
There are programs which take advantage of these rules that can be
rewritten--but not trivially--to work in the absence of overloading.
And the non-overloading version will be exponentially larger than the
version which uses overloading and generics.

     The case of generics with formal tagged type parameters is even
more complex.  (The ARG is trying to decide just how much more
complex. ;-)
--

					Robert I. Eachus

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

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Robert I. Eachus writes:

:   Okay... (This code is for demonstration purposes only...these
:features are useful, but not often used with predefined types or small
:generics.)
:
:   generic
:     with function "+"(L, R: Integer) return Integer is <>;
:   procedure Test(X,Y: in Integer);
:   
:   
:   with Text_IO;
:   procedure Test(X,Y: in Integer) is 
:   begin
:     Text_IO.Put_Line(" The sum of" & Integer'IMAGE(X) & " and" &
:               Integer'IMAGE(Y) & " is" & Integer'IMAGE(X+Y) & ".");
:   end Test;
:
:   with Test;
:   procedure Main is
:     procedure Test1 is new Test;
:
:     function "+"(L,R: Integer) return Integer
:     is begin return L*R; end "+";
:
:     procedure Test2 is new Test;
:   
:  begin 
:    Test1(5, 10);
:    Test2(5, 10);
:  end Main;
:
:spectre% main
: The sum of 5 and 10 is 15.
: The sum of 5 and 10 is 50.

Thanks for the example.

:     Notice that a much more normal situation would have the two
:instantiations in non-overlapping scopes, and the operator definitions
:coming from a package which defined some generic formal type.
:
:     What this is showing is not that it is possible to maliciously
:mess with definition of "+", 

Okay, we'll try to ignore that. :)

but that the fact that parameter matching
:for generic formal subprogram parameters uses overloading rules is
:significant.  It is a very useful feature to be able to instantiate a
:generic in a scope and inherit the local statically enclosing
:definitions of certain operations.  It is even more useful that the
:operations are selected based on the name of the function AND the
:parameter and return value profile.  You not only get the local
:operator, you get the right version to match the other generic
:formals.

Okay but the problem I have with this is that picking up the local stuff 
implicitly as parameters to the instantiation is potentially confusing
(as your example demonstrates). What would be clearer and less confusing, 
IMO, would be to declare the parametric information in a type together with 
the operation so that when you instantiate (explicitly) with that type 
(or a descendant type), you get the right operation with it. This way, it's 
very plain what the actual instantiation parameters are.

Not sure how you would write this in Ada. Maybe (excuse the syntax errors)

   type Some_Type is tagged ...
   function Some_Op (...) return Some_Type;

   generic
     type T is private;
   procedure Generic_Op (...);

   ...

   procedure Actual_Op is new Generic_Op (Some_Type);

The implicit resolution stuff is not a good idea, IMHO.

:     (Note that to get the local definitions of predefined operators
:for types, generic formal and otherwise, you need to explicitly
:declare those operators as generic formal subprograms.  But the at the
:point of the instantiation, defaults allow the user to ignore these
:"extra" formal parameters.)

Understand.

:     Now what does all this have to do with the no overloading model?
:There are programs which take advantage of these rules that can be
:rewritten--but not trivially--to work in the absence of overloading.
:And the non-overloading version will be exponentially larger than the
:version which uses overloading and generics.

If the non-overloading versions are exponentially larger, maybe the originals 
were a bit dodgy anyway. :)

:     The case of generics with formal tagged type parameters is even
:more complex.  (The ARG is trying to decide just how much more
:complex. ;-)

Sounds like a headache. :)

IMHO, overloading should have no semantic impact. It should merely be 
'syntactic sugar' as Jean-Marc suggested.


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

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

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

> Robert I. Eachus writes:
> 
> :significant.  It is a very useful feature to be able to instantiate a
> :generic in a scope and inherit the local statically enclosing
> :definitions of certain operations.  It is even more useful that the
> :operations are selected based on the name of the function AND the
> :parameter and return value profile.  You not only get the local
> :operator, you get the right version to match the other generic
> :formals.
> 
> Okay but the problem I have with this is that picking up the local stuff 
> implicitly as parameters to the instantiation is potentially confusing
> (as your example demonstrates). What would be clearer and less confusing, 
> IMO, would be to declare the parametric information in a type together with 
> the operation so that when you instantiate (explicitly) with that type 
> (or a descendant type), you get the right operation with it. This way, it's 
> very plain what the actual instantiation parameters are.
>
> Not sure how you would write this in Ada. Maybe (excuse the syntax errors) 

That's one of the "typical" uses for generic formal package parameters.  It
is one of the reasons they were included.

    generic
        type Some_Type is tagged private;
        with function Some_Op (...) return Some_Type;
    package X is end X;


    generic
        with package IX is new X(<>); -- No added constraints on Inst. of X
    procedure Generic_Op(...);


    package IX is new X(My_Type);
    procedure Actual_Op is new Generic_Op(IX);

An obvious variant that may prove useful in making sure things "line up"
correctly would be:

    generic
        type Some_Type is new My_Type with private;
        with package IX is new X(Some_Type);
    procedure Generic_Op(...);

Here, any supplied instance for IX must have been obtained via My_Type or
one of its descendants.


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

Re: Eiffel and Java + Ada dispatching

[Robert A Duff]

In article <E0JIJu.G98@syd.csa.com.au>,
Don Harrison <donh@syd.csa.com.au> wrote:
>...What would be clearer and less confusing, 
>IMO, would be to declare the parametric information in a type together with 
>the operation so that when you instantiate (explicitly) with that type 
>(or a descendant type), you get the right operation with it. This way, it's 
>very plain what the actual instantiation parameters are.
>
>Not sure how you would write this in Ada.

This feature exists in Ada 95.  Look up generic formal derived types in
the reference manual.  Basically, you declare in the generic that the
actual will be derived from some particular type, so inside the generic
you can call the operations inherited from that type, and at the
instantiation point, the compiler checks that the actual is in fact in
the correct class.  Programming by contract and all that good stuff.

- Bob

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Robert A Duff writes:

:Don Harrison <donh@syd.csa.com.au> wrote:
:>...What would be clearer and less confusing, 
:>IMO, would be to declare the parametric information in a type together with 
:>the operation so that when you instantiate (explicitly) with that type 
:>(or a descendant type), you get the right operation with it. This way, it's 
:>very plain what the actual instantiation parameters are.
:>
:>Not sure how you would write this in Ada.
:
:This feature exists in Ada 95.  

Yes. It was good to see it included. The ability to use a tagged type as the
formal parameter is especially useful. This mechanism is analogous to 
constrained genericity in Eiffel:

Ada                                             Eiffel
---                                             ------
generic                                         class X [T -> Some_Type] ...
  type Some_Type is tagged limited private;
package X ...

For Ada, X could also be a procedure or function.
 
:Look up generic formal derived types in
:the reference manual.  Basically, you declare in the generic that the
:actual will be derived from some particular type, so inside the generic
:you can call the operations inherited from that type, and at the
:instantiation point, the compiler checks that the actual is in fact in
:the correct class.  

Yes.

:Programming by contract and all that good stuff.

Yes, This is true of Eiffel. You get the benefit of all the contracting
defined in the type (and transitively, it's subtypes). But, you don't get
this in Ada as it does not support Programming by Contract in the more 
general (and usual) sense.


Jon Anthony writes:

:That's one of the "typical" uses for generic formal package parameters.  It
:is one of the reasons they were included.
:
:    generic
:        type Some_Type is tagged private;
:        with function Some_Op (...) return Some_Type;
:    package X is end X;
:
:
:    generic
:        with package IX is new X(<>); -- No added constraints on Inst. of X
:    procedure Generic_Op(...);
:
:
:    package IX is new X(My_Type);
:    procedure Actual_Op is new Generic_Op(IX);
:
:An obvious variant that may prove useful in making sure things "line up"
:correctly would be:
:
:    generic
:        type Some_Type is new My_Type with private;
:        with package IX is new X(Some_Type);
:    procedure Generic_Op(...);
:
:Here, any supplied instance for IX must have been obtained via My_Type or
:one of its descendants.

Thanks for the example. 

Sounds like a good argument for unifying module and type. :)  (No, I don't
want to debate that one again).


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

Re: Eiffel and Java + Ada dispatching

[Robert A Duff]

In article <E0qKM2.ECw@syd.csa.com.au>,
Don Harrison <donh@syd.csa.com.au> wrote:
>Ada                                             Eiffel
>---                                             ------
>generic                                         class X [T -> Some_Type] ...
>  type Some_Type is tagged limited private;
>package X ...

I meant "type Some_Type is new Other_Type with private".

>Yes, This is true of Eiffel. You get the benefit of all the contracting
>defined in the type (and transitively, it's subtypes). But, you don't get
>this in Ada as it does not support Programming by Contract in the more 
>general (and usual) sense.

I'm not sure what you mean by that.  That Ada doesn't have assertions?
True.  But there's all kinds of other contractual stuff in Ada -- when
you export a type from a package, you define a contract; that is, what
operations there are, and what their parameter names and types are, and
so forth.

- Bob

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Bob Duff writes:

:In article <E0qKM2.ECw@syd.csa.com.au>,
:Don Harrison <donh@syd.csa.com.au> wrote:
:>Ada                                             Eiffel
:>---                                             ------
:>generic                                         class X [T -> Some_Type] ...
:>  type Some_Type is tagged limited private;
:>package X ...
:
:I meant "type Some_Type is new Other_Type with private".

Okay. What's the difference?

:>Yes, This is true of Eiffel. You get the benefit of all the contracting
:>defined in the type (and transitively, it's subtypes). But, you don't get
:>this in Ada as it does not support Programming by Contract in the more 
:>general (and usual) sense.
:
:I'm not sure what you mean by that.  That Ada doesn't have assertions?

Yes.

:True.  But there's all kinds of other contractual stuff in Ada -- when
:you export a type from a package, you define a contract; that is, what
:operations there are, and what their parameter names and types are, and
:so forth.

Sure. This is certainly *part* of contracting but this stuff is what you'd 
expect of any sensible statically typed language so isn't anything startling. 
Static typing is good stuff but it's misleading, IMO, to say that Ada supports
Programming by Contract because the term is implies assertions as well.


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

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

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

> Bob Duff writes:
> 
> :In article <E0qKM2.ECw@syd.csa.com.au>,
> :Don Harrison <donh@syd.csa.com.au> wrote:
> :>Ada                                             Eiffel
> :>---                                             ------
> :>generic                                         class X [T -> Some_Type] ...
> :>  type Some_Type is tagged limited private;
> :>package X ...
> :
> :I meant "type Some_Type is new Other_Type with private".
> 
> Okay. What's the difference?

In the first, "Some_Type" is the generic formal (like the T in Eiffel)
and could be instantiated with anything.  In the second you have the
same as the Eiffel, which to make it explicit would have been written:

    type T is new Some_Type with private.

That's the same as the Eiffel constraint above...

/Jon

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

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Jon S Anthony writes:

:> :>  type Some_Type is tagged limited private;

:> :I meant "type Some_Type is new Other_Type with private".

:In the first, "Some_Type" is the generic formal (like the T in Eiffel)
:and could be instantiated with anything.  

Do you mean like the following?

  class X [T] ...              -- unconstrained genericity.

If so, this is different from what Bob Duff said.

In the second you have the
:same as the Eiffel, which to make it explicit would have been written:
:
:    type T is new Some_Type with private.
:
:That's the same as the Eiffel constraint above...

Same as Bob Duff.

BTW, I'll check the RM.


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

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

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

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

> Jon S Anthony writes:
> 
> :> :>  type Some_Type is tagged limited private;
> 
> :> :I meant "type Some_Type is new Other_Type with private".
> 
> :In the first, "Some_Type" is the generic formal (like the T in Eiffel)
> :and could be instantiated with anything.  
> 
> Do you mean like the following?
> 
>   class X [T] ...              -- unconstrained genericity.

Yes.


> If so, this is different from what Bob Duff said.

Huh?????  I went and checked and this is seems to be exactly what Bod said!
Here's what he said:


>> I believe Eiffel has something similar to both, but I forget the syntax.
>> Is this the "class X [Some_Type]" vs. "class X [Some_Type ->
>> Other_Type]" thing?  You can have a generic class where the formal can
>> be any class, or you can require the formal to be a subclass of some
>> particular class.
>> 
>> - Bob


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

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Jon S Anthony writes:

:> :> :>  type Some_Type is tagged limited private;

:> :"Some_Type" is the generic formal (like the T in Eiffel)
:> :and could be instantiated with anything.  
:> 
:> Do you mean like the following?
:> 
:>   class X [T] ...              -- unconstrained genericity.
:
:Yes.
:
:
:> If so, this is different from what Bob Duff said.
:
:Huh?????  I went and checked and this is seems to be exactly what Bod said!

Yes, You're right. My mistake. You were both saying this is unconstrained
genericity: an actual of any type may be substituted. Further, no operations
come with it (because the designer of the generic can't anticipate what 
actuals may be provided in instantiations).


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

Re: Eiffel and Java + Ada dispatching

[Robert A Duff]

In article <E0sIBu.MJz@syd.csa.com.au>,
Don Harrison <donh@syd.csa.com.au> wrote:
>:>generic                                         class X [T -> Some_Type] ...
>:>  type Some_Type is tagged limited private;
>:>package X ...
>:
>:I meant "type Some_Type is new Other_Type with private".
>
>Okay. What's the difference?

In the first example above, Some_Type doesn't have any primitive
operations.  You can't do much of anything with it, other than declare
objects and a few other minor things.  (Unless you pass in explicit
operations, which is what you (or somebody else?) was objecting to,
several messages ago.)

In the second example, Some_Type inherits all the primitive operations
of Other_Type.  Inside the generic, you can do dispatching calls to them
and so forth.  The actual type is required to be in the right class
(Other_Type'Class), and thus implements all of those things you're
calling.

I believe Eiffel has something similar to both, but I forget the syntax.
Is this the "class X [Some_Type]" vs. "class X [Some_Type ->
Other_Type]" thing?  You can have a generic class where the formal can
be any class, or you can require the formal to be a subclass of some
particular class.

- Bob

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Robert A Duff writes:

:>:>  type Some_Type is tagged limited private;

:>:I meant "type Some_Type is new Other_Type with private".

:In the first example above, Some_Type doesn't have any primitive
:operations.  You can't do much of anything with it, other than declare
:objects and a few other minor things.  (Unless you pass in explicit
:operations, which is what you (or somebody else?) was objecting to,
:several messages ago.)

I don't remember objecting but *was* curious about why operations had to be
explicitly declared as parameters along with types under some circumstances. :)
I expect this is a legacy of Ada-83.

:In the second example, Some_Type inherits all the primitive operations
:of Other_Type.  Inside the generic, you can do dispatching calls to them
:and so forth.  The actual type is required to be in the right class
:(Other_Type'Class), and thus implements all of those things you're
:calling.

This appears to be analogous to Eiffel's constrained genericity:

  class X [Some_Type -> Other_Type] ...

:I believe Eiffel has something similar to both, but I forget the syntax.

It has the 2nd type but not the first. This makes sense for Eiffel, IMO, 
because types potentially carry operations with them. These operations should 
be available wherever the type is used.

:Is this the "class X [Some_Type]" vs. "class X [Some_Type ->
:Other_Type]" thing?  You can have a generic class where the formal can
:be any class, or you can require the formal to be a subclass of some
:particular class.

That's right. The former is called 'unconstrained genericity'. As you would
expect, the operations also come with the type with this form.


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

Re: Eiffel and Java + Ada dispatching

[Joachim Durchholz]

bobduff@world.std.com wrote 12.11.96:

> I'm not sure what you mean by that.  That Ada doesn't have assertions?
> True.  But there's all kinds of other contractual stuff in Ada -- when
> you export a type from a package, you define a contract; that is, what
> operations there are, and what their parameter names and types are, and
> so forth.

This is the normal contract on parameter and result types. Eiffel  
contracts also include arbitrary boolean expressions, extending the  
contracting idea far into the area of program semantics.
Just as a parameter type makes clear what sorts of parameters are  
required, the preconditions make clear under what circumstances the  
routine may be called and expected to return a correct result. The Eiffel  
postconditions list what the routine guarantees to the caller in turn.

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 + Ada dispatching

[Richard Riehle]

On 12 Nov 1996, Joachim Durchholz wrote:


> This is the normal contract on parameter and result types. Eiffel  
> contracts also include arbitrary boolean expressions, extending the  
> contracting idea far into the area of program semantics.
> Just as a parameter type makes clear what sorts of parameters are  
> required, the preconditions make clear under what circumstances the  
> routine may be called and expected to return a correct result. The Eiffel  
> postconditions list what the routine guarantees to the caller in turn.

  It is not a question of whether Ada includes a contract in its
  package specifications.  The model for defining such a contract
  in Ada is a simple type definition with optional ranges and the
  set of operations for that type.  In object-oriented programming,
  to implement inheritance with class attribute extension (Ada has
  always had inheritance with attribute extension), on uses tagged
  types for the contract.

  I am fond of both Eiffel and Ada.  However, I sometimes wonder about
  the underlying reliability of assertions versus simple type definition.
  It seems to me that one can easily design an assertion that exceeds,
  in complexity, the wonderfully simple examples one sees published in
  Eiffel books. And as these assertions become more complex, are we 
  increasing the risk associated with that assertion.  

  I suspect that including assertions in Ada 95 would have made some
  practitioners happy. Would such a feature (no Eiffel pun intended)
  contribute to underlying reliability goals of Ada. Moreover, a
  fundamental notion in Ada is for the compiler to detect the maximum
  number of errors as close to the design specification as possible.
  Assertions are focused on run-time rather than comple-time.

  The structural differences between Ada and Eiffel are sometimes cited
  by advocates of both languages for their benefits.  Eiffel enthusiasts
  sometimes claim the "module is type" model is superior.  Though the
  case for this can be quite compelling, in software engineering practice
  the package model of Ada fares quite well.  Ada's separation of 
  specification from implementation contributes to a design that
  takes advantage of what Bertrand Meyer has called, "Linguistic
  Modular Units."  In Ada this is possible because we can define
  package specifications that are readable by our customers, by
  the systems engineers, and throughout all phases of the project.
  Such specifications can be straightforward in describing the
  "what" with little need to examine the "how."  

  I call this model of "Linguistic Modular Units" in Ada, a 
  Project Level Linguistic Backplane.  Whenver my clients have
  taken this approach, using Ada as the linguistic backplane for
  their entire project, they find it quite useful.  

  I find it entirely too easy to include algorithmic details in
  the definition of an Eiffel class. Consequently, I believe the
  Ada separation of specification from body compensates for its
  lack of an explicit assertion model.  Moreover, the very fact
  of a type definition, along with the rules for types, constitutes
  an implicit notion of precondition, postcondition, and invariant
  that is checked quite rigorously by the Ada run-time.

  Richard Riehle

  

Interfacing contracts (Was: Eiffel and Java + Ada dispatching)

[Geert Bosch]

Joachim Durchholz (jhd@herold.franken.de) wrote:
  "This is the normal contract on parameter and result types. Eiffel  
   contracts also include arbitrary boolean expressions, extending the  
   contracting idea far into the area of program semantics.
   Just as a parameter type makes clear what sorts of parameters are  
   required, the preconditions make clear under what circumstances the  
   routine may be called and expected to return a correct result. The Eiffel  
   postconditions list what the routine guarantees to the caller in turn."

Although Ada's interface capabilities are good enough to define the
range of results, these extra capabilities of Eiffel are very useful indeed. 
Especially for the large programs that are built using Ada. 

Something I'd really like to have is an Ada extension for specifying
both interface constraints and implementation conditions. 

Example for interface specification that might be accepted by
an Ada implementation without violating the Ada-95 standard (yes?):

   --  Integer square root function truncating the exact result
   function Square_Root (I : Natural) return Natural;

   for Square_Root'Post_Condition use
      Square_Root (I)  ** 2 <= I and (Square_Root (I) + 1) ** 2 > I;

In implementation:
   function Square_Root (I : Natural) return Natural is
      Lowerbound : Natural := Natural'Min (2, I);
      for Lowerbound'Invariant use Lowerbound ** 2 <= I;
      ...
   begin
      ...
   end Square_Root;

The advantage of checkng the pre- and post-conditions is that
the user of the subprogram or primitive has a better specification
of what the function (or procedure or...) does. The advantage of
a machine checkable specification is that the user can rely on them.
Ordinary comments on the other hand are often out of date.

Also when my algorithm using the Square_Root function specified
above doesn't work correctly, I only have to look at the specification
to know that the error won't be in the Square_Root implementation.
This is much better than to try figuring out whether the Code is correct
or not. Using a pragma Assert on the computed value just before return
has some drawbacks: you have to look at the implementation to know whether
these assertions are present, and you have to make sure that all possible
returns from the function are checked.

Another point is that it is possible in many cases to automatically
prove invariants. When the proving software cannot prove invariants,
the programmer can (and maybe should) make smaller steps that are
easier to prove. When all invariants can be proved, no checks are
necessary so speed is the same.

Actually it might be possible for the compiler to take advantage of
invariants and pre- / post-conditions by both eliminating checks and
taking advantage of the extra information.
    
Note that in the examples above, the formal parameters are visible
in the expression and that the expression is in fact a function.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl    

Re: Interfacing contracts (Was: Eiffel and Java + Ada dispatching)

[Robert A Duff]

In article <56kgrf$61t@fozzie.sun3.iaf.nl>,
Geert Bosch <geert@fozzie.sun3.iaf.nl> wrote:
>Example for interface specification that might be accepted by
>an Ada implementation without violating the Ada-95 standard (yes?):
>
>   --  Integer square root function truncating the exact result
>   function Square_Root (I : Natural) return Natural;
>
>   for Square_Root'Post_Condition use
>      Square_Root (I)  ** 2 <= I and (Square_Root (I) + 1) ** 2 > I;

Well, 13.1(19) says that expression is evaluated at this point, which is
not what you want.

You could use specially-formatted comments, as SPARK does.

By the way, I think invariants (not loop invariants, but per-class
invariants) are the most interesting thing about Eiffel's assertion
facility.

- Bob

Re: Eiffel and Java + Ada dispatching

[Robert I. Eachus]

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

  > Okay but the problem I have with this is that picking up the local
  > stuff implicitly as parameters to the instantiation is potentially
  > confusing (as your example demonstrates). What would be clearer
  > and less confusing, IMO, would be to declare the parametric
  > information in a type together with the operation so that when you
  > instantiate (explicitly) with that type (or a descendant type),
  > you get the right operation with it. This way, it's very plain
  > what the actual instantiation parameters are.

   In Ada, the default for generics is that you get the "predefined"
operations for the class.  But if you explicitly pass the operation as
a generic formal, you can override the standard definition.  No
surprise there either.  The suprise in the construct I demonstrated is
that it is possible to define generics that are sensitive to the
environment where they are instantiated.

   And yes, it is a very useful feature, and should be used very
carefully.  I have written several Ada 83 libraries where generics
have use this feature extensively, and have as many as thirty formal
parameters.  Since the packages are intended to be useful, they also
are designed so that most of the generic formals have default values,
so the instantiations only need a few lines.

   But it is a high (and almost lanaguage independent) talent to
observe the principle of least surprise.

  > If the non-overloading versions are exponentially larger, maybe
  > the originals were a bit dodgy anyway. :)

   No, but the most extreme case I know of was real portmanteau code.
Generic instantiations with other generic instantiations as
parameters, about four levels deep.  But any other way of writing the
code would have required millions of lines of code.  The several
thousand generic instantiations weren't easy to debug and test, but
much much better than any million line monstrosity would have been.
Just don't use the powerful features for the easy jobs, save them for
when and where they are needed.

  > IMHO, overloading should have no semantic impact. It should merely be 
  > 'syntactic sugar' as Jean-Marc suggested.
 
   Nice dream, but...the fact that horses are a good way to commute
shouldn't lead to the outlawing of jet planes for intercontinental
travel.  However, you do need to make sure that the airplane pilot
knows how to fly. ;-)


--

					Robert I. Eachus

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

Re: Eiffel and Java + Ada dispatching

[Robert A Duff]

In article <EACHUS.96Nov13204034@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:
>   No, but the most extreme case I know of was real portmanteau code.

What, exactly, is 'portmanteau code'?

- Bob

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Robert I. Eachus writes:

:   In Ada, the default for generics is that you get the "predefined"
:operations for the class.  But if you explicitly pass the operation as
:a generic formal, you can override the standard definition.  No
:surprise there either.  

Okay. If it made sense, I think I would prefer to encapsulate behaviour of 
related operations into a type and define descendants covering the variants. 
Then the parent type bundled with its operations can be used as a formal 
generic parameter. That way, you simplify the generic interface. Don't know 
whether this fits at all.

:The suprise in the construct I demonstrated is
:that it is possible to define generics that are sensitive to the
:environment where they are instantiated.
:
:   And yes, it is a very useful feature, and should be used very
:carefully.  I have written several Ada 83 libraries where generics
:have use this feature extensively, and have as many as thirty formal
:parameters.  Since the packages are intended to be useful, they also
:are designed so that most of the generic formals have default values,
:so the instantiations only need a few lines.

If you were writing this now in Ada95, would you be able to reduce the 
complexity by using OO stuff?

:   But it is a high (and almost lanaguage independent) talent to
:observe the principle of least surprise.

Indeed. :)

:  > If the non-overloading versions are exponentially larger, maybe
:  > the originals were a bit dodgy anyway. :)

In saying this, I didn't realise you were talking about Ada83. It makes more
sense in that context.

:   No, but the most extreme case I know of was real portmanteau code.
:Generic instantiations with other generic instantiations as
:parameters, about four levels deep.  

Nasty stuff!

:But any other way of writing the
:code would have required millions of lines of code.  The several
:thousand generic instantiations weren't easy to debug and test, but
:much much better than any million line monstrosity would have been.
:Just don't use the powerful features for the easy jobs, save them for
:when and where they are needed.

I'll interpret 'powerful' to mean 'esoteric'. :)

:  > IMHO, overloading should have no semantic impact. It should merely be 
:  > 'syntactic sugar' as Jean-Marc suggested.
: 
:   Nice dream, but...the fact that horses are a good way to commute
:shouldn't lead to the outlawing of jet planes for intercontinental
:travel.  However, you do need to make sure that the airplane pilot
:knows how to fly. ;-)

Yes, and thankfully they make planes *easier* to fly these days. :)

Jon should know something about that.


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

Re: Eiffel and Java + Ada dispatching

[Robert I. Eachus]

   I said:

   :   In Ada, the default for generics is that you get the "predefined"
   :operations for the class.  But if you explicitly pass the operation as
   :a generic formal, you can override the standard definition.  No
   :surprise there either.  

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

  > Okay. If it made sense, I think I would prefer to encapsulate
  > behaviour of related operations into a type and define descendants
  > covering the variants.  Then the parent type bundled with its
  > operations can be used as a formal generic parameter. That way,
  > you simplify the generic interface. Don't know whether this fits
  > at all.

   Exactly, and that is the usual case.  But there are cases where you
want to have several very similar methods/functions/operations (choose
your term) that are slightly different.  In Ada you can do this
tailoring with generic formal subprogram parameters.  For a hackneyed
example say you want to write a Runge-Kutta integration routine.  It
is nice to be able to make it a generic (with respect to the type of
the integrand) and to call it with values for the function to be
integrated and the bounds.

   In Ada you get to choose between THREE places where parameters and
methods can be fixed:  At the point where generic definition appears,
at the point where the generic instantiation occurs, and at the point
of the call.  The "tricky bit" is that you can also have overridable
defaults bound at any of those three locations.  I don't know why you
would want to provide a RK routine where the default number of steps
was set during instantiation, but you can do it if you want to.

  > If you were writing this now in Ada95, would you be able to reduce
  > the complexity by using OO stuff?

   No, and no!  First, the complexity is not in the code, it is in the
understanding of the requirements.  Second, if those are the
requirements, the same solution is probably the simplest in Ada 83 and
Ada 95.

   This is a symptom of a general problem for OO programmers learning
Ada.  In Ada generics are often a much simpler, and hugely more
maintainable solution to many problems that can only be solved with
inheritance in other OO languages.  As a result in well written Ada 95
code, it is rare for a class to have grandchildren.  (Hmmm.  Better
stated as almost all grandchildren are descended from Controlled or
Limited_Controlled.)  But it is not uncommon for a derived tagged type
declaration to be followed by several generic instantiations that
would have be done in some other languages by multiple inheritance.

    My favorite illustration of this uses lists.  In Ada if you create
a class by specialization, and want to be able to make lists of the
members you will almost certainly use a generic.  In other languages
you would inherit from both the general class and a list class.

    Is this because you can't do it the other way?  No, it is because
it usually turns out to be cleaner to have both list objects and
objects which can be members of lists.  Ada makes it easy to do this,
and without loss of generality in the list class, so that is usually
the best way to do it.  (Why is it better to have two types?
Overloading again.  If the types are different, then it is possible to
provide (with one, one-line instantiation) among other operations:

     function "&" (L,R: Element) return List;
     function "&" (L: Element; R: List) return List;
     function "&" (L: List; R: Element) return List;
     function "&" (L,R: List) return List;

    ...and get the expected semantics.  If the types are the same,
then there is no way to distinguish between a list containing one
element and an element.

  > I'll interpret 'powerful' to mean 'esoteric'. :)

  No, I meant powerful.  Just like working with rocket fuel or
high-voltage electicity or what have you.  When you are working with
constructs where the change of one word, say a parameter name, can
have a global effect on modules which never use that name, you have to
use design principles and configuration manangement tools very
different from the run of the mill.

   (Just so I don't scare anyone off, what I usually do is when
overloading operations or overriding methods, I use the same parameter
names.  This makes it clear that you never intend to use parameter
names in overload resolution, just to match parameter values to
formals.)

--

					Robert I. Eachus

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

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Robert I. Eachus writes:

:   In Ada you get to choose between THREE places where parameters and
:methods can be fixed:  At the point where generic definition appears,
:at the point where the generic instantiation occurs, and at the point
:of the call.  

That sounds about the same as Eiffel.

:The "tricky bit" is that you can also have overridable
:defaults bound at any of those three locations.  I don't know why you
:would want to provide a RK routine where the default number of steps
:was set during instantiation, but you can do it if you want to.

I'd have to say that I never instantiate anything in Ada without explicitly 
providing actual parameters. I think it makes it easier to see what's going 
on at the instantiation site without having to check the generic declaration 
to see that a default isn't unwittingly being used. So, rather than being 
disappointed that Eiffel doesn't have default actual parameters, I'm glad 
that it doesn't.

:  > If you were writing this now in Ada95, would you be able to reduce
:  > the complexity by using OO stuff?
:
:   No, and no!  First, the complexity is not in the code, it is in the
:understanding of the requirements.  Second, if those are the
:requirements, the same solution is probably the simplest in Ada 83 and
:Ada 95.

I'll take your word for it. 

:   This is a symptom of a general problem for OO programmers learning
:Ada.  In Ada generics are often a much simpler, and hugely more
:maintainable solution to many problems that can only be solved with
:inheritance in other OO languages.  

Yes, generics are useful. I'm glad they are in Eiffel. However, if I had to
choose between generics and inheritance, I would choose inheritance. I recall
Bertrand Meyer saying in OOSC that you can emulate generics using inheritance
but not the reverse.

:  > I'll interpret 'powerful' to mean 'esoteric'. :)
:
:  No, I meant powerful.  Just like working with rocket fuel or
:high-voltage electicity or what have you.  When you are working with
:constructs where the change of one word, say a parameter name, can
:have a global effect on modules which never use that name, you have to
:use design principles and configuration manangement tools very
:different from the run of the mill.

If it's all the same to you, I'll stick to 'the run of the mill'. :)


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

Re: Eiffel and Java + Ada dispatching

[Vincent Celier]

Don Harrison wrote:

> I'd have to say that I never instantiate anything in Ada without explicitly
> providing actual parameters. I think it makes it easier to see what's going
> on at the instantiation site without having to check the generic declaration
> to see that a default isn't unwittingly being used. So, rather than being
> disappointed that Eiffel doesn't have default actual parameters, I'm glad
> that it doesn't.
> 

Default parameters are very useful when low-level interfaces need to
migrate.

To remove a generic formal:
   1- Add a default: upwardly change, no client code should be
      affected,
   2- Ask all client to remove the obsolete parameter in their
instantiations
   3- When all clients have done 2, remove the generic formal.

To add a new generic formal:
   1- Add the new generic formal, with a default,
   2- Ask all clients to add an actual parameter in all instantiatrions,
   3- Remove the default.

This work well for constants of global types, and for subprograms
with parameters and return values of global types.
For values of generic private types, it is sometimes possible to add a
new generic
constant, if there is already another generic constant.

For example, in the following spec:

   generic
      type Item is private;
      Nil_Item : in Item;
   package Whatever_Generic is ...

it is possible to introduce a new generic constant of type Item:

   generic
      type Item is private;
      Nil_Item : in Item;
      Default_Item : in Item := Nil_Item;
   package Whatever_Generic is ...


However, it is not possible to default generic formal types and
variables. Other
techniques should then be used.

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

-- Vincent Celier,
-- 9100 McCutcheon Place, RICHMOND, B.C.
-- CANADA, V7A 5A5
-- +1 (604) 241-9811
--
-- Always looking for experienced Ada developpers willing to live in
BBC,
-- (Beautiful British Columbia).

Re: Eiffel and Java + Ada dispatching

[Don Harrison]

Vincent Celier writes:

:Don Harrison wrote:
:
:> I'd have to say that I never instantiate anything in Ada without explicitly
:> providing actual parameters. I think it makes it easier to see what's going
:> on at the instantiation site without having to check the generic declaration
:> to see that a default isn't unwittingly being used. So, rather than being
:> disappointed that Eiffel doesn't have default actual parameters, I'm glad
:> that it doesn't.

:Default parameters are very useful when low-level interfaces need to
:migrate.
:
:To remove a generic formal:
:   1- Add a default: upwardly change, no client code should be
:      affected,
:   2- Ask all client to remove the obsolete parameter in their
:instantiations
:   3- When all clients have done 2, remove the generic formal.
:
:To add a new generic formal:
:   1- Add the new generic formal, with a default,
:   2- Ask all clients to add an actual parameter in all instantiatrions,
:   3- Remove the default.

Yes, this technique works. We've used it here occasionally with Ada-83 and
I agree it's appropriate in that context.

However, in an OO context, I would do it differently:

1) Define a new generic class inheriting the stuff it needs (from the original 
   or an ancestor thereof) and adding whatever new stuff it requires.
2) Convert clients when convenient to use the new generic.

This way, you retain the benefit of being able to see the parameters at the
site of instantiation and avoid the transitional state of obsolesence.

:-- Always looking for experienced Ada developpers willing to live in
:BBC,
:-- (Beautiful British Columbia).

You mean they need to be persuaded? :)  Some people don't know what's good 
for them.


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

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

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

> :  > IMHO, overloading should have no semantic impact. It should merely be 
> :  > 'syntactic sugar' as Jean-Marc suggested.
> : 
> :   Nice dream, but...the fact that horses are a good way to commute
> :shouldn't lead to the outlawing of jet planes for intercontinental
> :travel.  However, you do need to make sure that the airplane pilot
> :knows how to fly. ;-)
> 
> Yes, and thankfully they make planes *easier* to fly these days. :)
> 
> Jon should know something about that.
> 
> 
> Don.

I guess it depends on what you mean by "easier".  If all you want to
do is straight and level, A to B stuff, I suppose you may have a
point.  However, if you are going to do competition aerobatics or air
show work, the airplane you're going to want for "ease" of use (if you
are sane) will have zero in common with the previous sense of "ease".

Which only goes to show how very context dependent such "value
judgements" tend to be.

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

Re: portmanteau (was Re: Eiffel and Java + Ada dispatching)

[Robert I. Eachus]

In article <E0vMwK.BzE@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

  > What, exactly, is 'portmanteau code'?

   Sheeesh, go and any of several standard texts on the subject of
software engineering, by one of the pioneers in the study of Boolean
logic, Charles Dodgson, writing under some pseudonym.  I think the
discussion actually occurs in the introduction to "The Hunting of the
Snark."  In any case he is discussing "Jabberwocky," and uses the term
portmanteau words to decribe words with more than one meaning packed
into them.  (See also in "Through the Looking Glass" the conversation
between Alice and Humpty Dumpty.)

   So portmanteau code is a section of program code which not only can
be read in more than one way, but all meanings are there and
accessable.  Unix has lots of portmanteau commands, where either the
arguements determine the meaning, such as setenv, or the name by which
the executable is invoked determines the operation to be performed
such as compress.

    (A portmanteau is a type of suitcase which folds up and can be
opened in different ways when folded and unfolded.  Many portmanteaus
are sold today as luggage designed to be carried on aircraft.)

    Totally off the subject, but one upon a time I wrote some
portmanteau machine code.  Two completely different programs for an
IBM 3033. (It wouldn't work on those 360/370 architecture machines
which required instrutions to be aligned. ;-) You executed the second
program by starting one byte after the starting point of the first
program.  (Of course I cheated, there were only about 70 byte
interleaved instructions in the code.)



--

					Robert I. Eachus

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

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

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

> However, the central difference is that dynamic binding is always there in  
> Eiffel. You don't have to rewrite Eiffel code to make overloading work,  
> you just don't use polymorphism. You'd have to rewrite Ada code to go from  
> overloading to dynamic binding.

This is a category error.  Overloading is not the same sort of thing
as dynamic binding.  The counterpart that you want is static binding.
A reasonable (though certainly not exact) counter part ot overloading
in this context would be "covariance".  Overloading affects what
operation will be dynamically bound in an invocation, but it in no way
affects _whether_ the invocation is dynamically bound.

/Jon

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

Re: Eiffel and Java + Ada dispatching

[Robb Nebbe]

Joachim Durchholz wrote:

> However, the central difference is that dynamic binding is always there in
> Eiffel. You don't have to rewrite Eiffel code to make overloading work,
> you just don't use polymorphism. You'd have to rewrite Ada code to go from
> overloading to dynamic binding.

If you need dynamic binding then it certainly isn't overloading that you would
use to replace it. Overloading and dispatching are certainly related language
mechanisms but not in this way. Ada has both dispatching and overlaoding.
Eiffel has just dispatching. However, some of what Eiffel does with
dispatching Ada does with overloading.

This is because it is much easier to reason about polymorphism locally in Ada
than it is in Eiffel. When there is no dispatching Ada uses overloading to
resolve which operation is invoked. In contrast Eiffel always uses the
dispatching rules but the dispatch might be optimized away. So if someone says
overloading in Ada is bad do they mean the part that overlaps with dispatching
in Eiffel or the part that goes beyond what you can do in Eiffel?  

If you adopt an Eiffel point of view and ask yourself what would overloading
give me that Eiffel doesn't already provide then you come to the conclusion
that there really isn't any major reason to add overloading to Eiffel.
However, you can not conclude that you can just rip overloading out of any
language because it might play a more important role in some other language,
such as Ada.

Generalizing knowledge about one language to another language is very
difficult without an intimate understanding of the other language. The real
kicker is it is also very difficult to know when you have achieved this level
of undertanding :-)

Robb Nebbe

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

In article <55p0i3$2u4@tjnews.is.s.u-tokyo.ac.jp> jezequel@piccolo.is.s.u-tokyo.ac.jp (Jean-Marc Jezequel) writes:


> >You are correct in saying that there is no semantic difference between
> >unique names and overloading. However, just because there is no semantic
> >difference don't suppose that it doesn't play a critical role in how the language
> >is defined. 
> 
> Yes, it does. For example by making things much more complicated;-)

Let's look at this in a different way.  Suppose that we didn't have any
overloading.  What would happen to the object model?  Suppose we have

    type A is tagged ...
...
    type B is new A with ...
...

    type P is tagged ...
    function Op ( x : P;  y : A ) return Something;
...
    type C is new P with ...
    -- Here we want to "refine" Op based on y having type B (covariant thing)

Now what?  Does C inherit Op from P?  If so, is Op covariant on the
second parameter?  Suppose we want to refine it, then what?  I suppose
we would need to introduce something like the "redefines" clause of
Eiffel lest we have name clashes.  Also, at the time we would've been
doing this, system validity issues associated with covariant
operations would be well known in the field.  What do we do about that?
- especially since one of the fundamental precepts of Ada has always
been to avoid introducing such potential errors.

So, we give up on covariance.  Now what?  We could (taking Don's
suggestion) just disallow another Op for C.  If you want to "refine"
based on the second parameter, you just have to use a different name.
But, that would severely constrain the ability to progam by extension
and in so doing, remove a good piece of why you even bother with OO
construction.

OK, we could try contravariance (ala' Sather).  But now how do we
introduce "refinements" of operations based on their non controlling
parameters?  We've come full circle - use overloading.


It's these sort of issues which (IMO) clearly show that OL is not just
syntactic sugar.  Not by a _long_ way.  It's presence has significant
semantic ramifications for what the object model even is.


> Despite Ada95 being much more clear than C++ in this respect, in complex cases involving
> both overloading and dynamic binding, it is still hardly possible to
> explain in one short sentence (like above) the concept of what's going on.
> 

> Just to change the subject, does anyone know why the designers of
> Ada95 did not choose to include the true multiple-dispatch a la CLOS
> (or point to a reference on this)?  At leat the syntax have been a
> problem; whereas it is in Java/C++/Eiffel.

Maybe Tucker will say something here, but the only thing I have ever
able to determine is that 1) no one knew what the "right" resolution
technique should be when you had multiple distinct types involved
(what's the effective method) and 2) no one really entertained trying
to put in something as complex as the MOP in order to get around 1).

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

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

[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

[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 + Ada dispatching

[Jon S Anthony]

In article <55c9e4$59m@tjnews.is.s.u-tokyo.ac.jp> jezequel@piccolo.is.s.u-tokyo.ac.jp (Jean-Marc Jezequel) writes:

> >> 2) but this is combined with the static overloading inherited from
> >> Ada83; which is merely syntactic sugar for routine having
> >> (statically) different signatures.
> >
> >Criminey!  This is wrong too.  It is not "merely syntactic sugar", as it
> >is part and parcel of why Ada does not need any system validity checks!
> 
> I do not claim to be any expert in Ada95: actually I practiced Ada83 only.
> So I might be wrong. In that case I would admit it without problem.
> But you cannot simply say: you are wrong and stay at this level of generality

Right - I wrote another note stating a bit about this.  The full knock down
drag out is in a thread called "Real OO" posted to c.l.a,c.l.e,comp.object
back in fall '95.


> What has "static overloading" to do with "system validity checks" ?
> If it is not syntactic sugar, please tell us what it is. Or if
> you're lazy, give a pointer to a relevant section of the reference
> manual, or to another easily accessible litterature.

Yes, I am getting lazy on this stuff - the pointer is above.  In fact,
I really should just stop wasting time on this...


> >> In this respect, it is exactly like C++ or Java, but for the
> >> symetric syntax.
> >
> >This isn't correct either.  There are some other semantic aspects
> >floating around that make it different from C++/Java in this area.
> 
> I didn't say (god forbid!) that Ada95 was anywhere the same as C++/Java!
> I was limiting the scope of my comment to the ability
> of having both *overloading* and *single dispatch*. 

So was I.  The "overloading" bit is different from J/C++ for a few
reasons which I pointed out in another note (and which depend in part
on the distinction between specific and class wide types, which are
analogous to Sather concrete and abstract classes).


> Do you find it funny to cut one's statements at strategic points to distort
> their meaning, or what? Sorry, but I still believe in good faith discussions.

No - and I didn't do this.  The important bit is "In this respect" -
which refers to the business of overloading - not languages in
general.  And to say that "in this respect" it (Ada) is _exactly_ like
the other two (C++/J) is not correct.


> And this has not to degenerate in a language war: Ada and Eiffel
> deserve better than that.

Right.  Besides, that's been done to death and its boring.


> My only point in this post was that mixing *overloading* (a static
> mechanism AFAIK) with *single dispatch* dynamic binding, using the
> same syntax for the call, was making things a bit confusing for the
> user of the language. Since this is a subjective point, I have no
> problem with you not agreeing with me. But I expect real arguments
> on your side to be able to explain it myself to others.

Sounds right.  As I point out in another note, this "confusing"
assesement stems in large part from not being familiar with the
distinction between specific and class-wide types.  It is worth noting
that in C++/J this distinction is not made and the confusion really
does have a more "objective" basis.


> But I do not claim Eiffel is perfect (can you claim Ada95 is?).

Are you kidding? :-) I have flamed Ada on a number of points.  What I
don't like is seeing someone make assertions which do not reflect
various facts.  I'm sure I've made these sort of assertions too as
people have "shown me the error of my ways".  I'm not going to go
around making assertions about Eiffel here without first making pretty
damn sure I understand the relevant bits in ETL and related
information.


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

Re: Eiffel and Java + Ada dispatching

[Jon S Anthony]

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

> jsa@alexandria wrote 31.10.96:
> 
> > I guess you like system validity problems.

I wish I hadn't said this - it was too flip.


> *However*, there is a proposal floating around that allows static type  
> checking without having to resort to system-wide checks, and this is  
> commonly regarded as an advance over system validity and run-time checks.

I've heard about this - is there a pointer to the details?  On the Eiffel
home page?

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

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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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 <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 + Ada dispatching

[Joachim Durchholz]

jsa@alexandria wrote 02.11.96:

> > *However*, there is a proposal floating around that allows static type
> > checking without having to resort to system-wide checks, and this is
> > commonly regarded as an advance over system validity and run-time checks.
>
> I've heard about this - is there a pointer to the details?  On the Eiffel
> home page?

Yes. Go to www.eiffel.com and follow the Technology Papers (or something  
like that) link.
BTW the proposal doesn't solve *all* problems. The real problem is with  
covariant parameter redefinitions, which are necessary to do certain neat  
stuff (like parallel type hierarchies as in TREE-BINARY_TREE and NODE- 
BINARY_NODE) and cause all sorts of trouble and type holes. I'm not aware  
of a good, elegant solution, however.

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

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