* Eiffel and Java @ 1996-10-27 0:00 Vincent WEBER 1996-10-27 0:00 ` Jean-Michel P. Decombe ` (9 more replies) 0 siblings, 10 replies; 168+ messages in thread From: Vincent WEBER @ 1996-10-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 Eiffel and Java Vincent WEBER @ 1996-10-27 0:00 ` Jean-Michel P. Decombe 1996-10-28 0:00 ` David Hanley ` (4 more replies) 1996-10-28 0:00 ` Matthew Heaney ` (8 subsequent siblings) 9 siblings, 5 replies; 168+ messages in thread From: Jean-Michel P. Decombe @ 1996-10-27 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 ` Jean-Michel P. Decombe @ 1996-10-28 0:00 ` David Hanley 1996-10-28 0:00 ` Matt Kennel 1996-10-28 0:00 ` Alexandre Oliva ` (3 subsequent siblings) 4 siblings, 1 reply; 168+ messages in thread From: David Hanley @ 1996-10-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-28 0:00 ` David Hanley @ 1996-10-28 0:00 ` Matt Kennel 0 siblings, 0 replies; 168+ messages in thread From: Matt Kennel @ 1996-10-28 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 ` Jean-Michel P. Decombe 1996-10-28 0:00 ` David Hanley @ 1996-10-28 0:00 ` Alexandre Oliva 1996-10-28 0:00 ` Robert Dewar ` (2 subsequent siblings) 4 siblings, 0 replies; 168+ messages in thread From: Alexandre Oliva @ 1996-10-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 ` Jean-Michel P. Decombe 1996-10-28 0:00 ` David Hanley 1996-10-28 0:00 ` Alexandre Oliva @ 1996-10-28 0:00 ` Robert Dewar 1996-10-31 0:00 ` Doug Marker 1996-10-29 0:00 ` Chris Trimble 1996-10-31 0:00 ` David Bennett 4 siblings, 1 reply; 168+ messages in thread From: Robert Dewar @ 1996-10-28 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-28 0:00 ` Robert Dewar @ 1996-10-31 0:00 ` Doug Marker 0 siblings, 0 replies; 168+ messages in thread From: Doug Marker @ 1996-10-31 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 ` Jean-Michel P. Decombe ` (2 preceding siblings ...) 1996-10-28 0:00 ` Robert Dewar @ 1996-10-29 0:00 ` Chris Trimble 1996-10-31 0:00 ` Doug Marker 1996-10-31 0:00 ` David Bennett 4 siblings, 1 reply; 168+ messages in thread From: Chris Trimble @ 1996-10-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Chris Trimble @ 1996-10-31 0:00 ` Doug Marker 0 siblings, 0 replies; 168+ messages in thread From: Doug Marker @ 1996-10-31 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 ` Jean-Michel P. Decombe ` (3 preceding siblings ...) 1996-10-29 0:00 ` Chris Trimble @ 1996-10-31 0:00 ` David Bennett 4 siblings, 0 replies; 168+ messages in thread From: David Bennett @ 1996-10-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 Eiffel and Java Vincent WEBER 1996-10-27 0:00 ` Jean-Michel P. Decombe @ 1996-10-28 0:00 ` Matthew Heaney 1996-10-29 0:00 ` Vincent WEBER ` (8 more replies) 1996-10-28 0:00 ` Larry Kilgallen ` (7 subsequent siblings) 9 siblings, 9 replies; 168+ messages in thread From: Matthew Heaney @ 1996-10-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-28 0:00 ` Matthew Heaney @ 1996-10-29 0:00 ` Vincent WEBER 1996-10-31 0:00 ` James McKim 1996-10-30 0:00 ` Jon S Anthony ` (7 subsequent siblings) 8 siblings, 1 reply; 168+ messages in thread From: Vincent WEBER @ 1996-10-29 0:00 UTC (permalink / raw) 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 ? :) > > ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Vincent WEBER @ 1996-10-31 0:00 ` James McKim 1996-11-01 0:00 ` Matthew Heaney 0 siblings, 1 reply; 168+ messages in thread From: James McKim @ 1996-10-31 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-31 0:00 ` James McKim @ 1996-11-01 0:00 ` Matthew Heaney 1996-11-04 0:00 ` James McKim 0 siblings, 1 reply; 168+ messages in thread From: Matthew Heaney @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-01 0:00 ` Matthew Heaney @ 1996-11-04 0:00 ` James McKim 0 siblings, 0 replies; 168+ messages in thread From: James McKim @ 1996-11-04 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-28 0:00 ` Matthew Heaney 1996-10-29 0:00 ` Vincent WEBER @ 1996-10-30 0:00 ` Jon S Anthony 1996-11-01 0:00 ` Eiffel and Java + Ada dispatching Jean-Marc Jezequel 1996-10-30 0:00 ` Eiffel and Java Don Harrison ` (6 subsequent siblings) 8 siblings, 1 reply; 168+ messages in thread From: Jon S Anthony @ 1996-10-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-30 0:00 ` Jon S Anthony @ 1996-11-01 0:00 ` Jean-Marc Jezequel 0 siblings, 0 replies; 168+ messages in thread From: Jean-Marc Jezequel @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-28 0:00 ` Matthew Heaney 1996-10-29 0:00 ` Vincent WEBER 1996-10-30 0:00 ` Jon S Anthony @ 1996-10-30 0:00 ` Don Harrison 1996-10-31 0:00 ` James McKim 1996-10-31 0:00 ` Joachim Durchholz ` (5 subsequent siblings) 8 siblings, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-10-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-30 0:00 ` Eiffel and Java Don Harrison @ 1996-10-31 0:00 ` James McKim 1996-11-04 0:00 ` Don Harrison 1996-11-23 0:00 ` Van Snyder 0 siblings, 2 replies; 168+ messages in thread From: James McKim @ 1996-10-31 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-31 0:00 ` James McKim @ 1996-11-04 0:00 ` Don Harrison 1996-11-23 0:00 ` Van Snyder 1 sibling, 0 replies; 168+ messages in thread From: Don Harrison @ 1996-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-31 0:00 ` James McKim 1996-11-04 0:00 ` Don Harrison @ 1996-11-23 0:00 ` Van Snyder 1 sibling, 0 replies; 168+ messages in thread From: Van Snyder @ 1996-11-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-28 0:00 ` Matthew Heaney ` (2 preceding siblings ...) 1996-10-30 0:00 ` Eiffel and Java Don Harrison @ 1996-10-31 0:00 ` Joachim Durchholz 1996-11-01 0:00 ` Norman H. Cohen ` (4 subsequent siblings) 8 siblings, 0 replies; 168+ messages in thread From: Joachim Durchholz @ 1996-10-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-28 0:00 ` Matthew Heaney ` (3 preceding siblings ...) 1996-10-31 0:00 ` Joachim Durchholz @ 1996-11-01 0:00 ` Norman H. Cohen 1996-11-02 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony ` (3 subsequent siblings) 8 siblings, 0 replies; 168+ messages in thread From: Norman H. Cohen @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-28 0:00 ` Matthew Heaney ` (4 preceding siblings ...) 1996-11-01 0:00 ` Norman H. Cohen @ 1996-11-02 0:00 ` Jon S Anthony 1996-11-02 0:00 ` Eiffel and Java Jon S Anthony ` (2 subsequent siblings) 8 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-28 0:00 ` Matthew Heaney ` (5 preceding siblings ...) 1996-11-02 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony @ 1996-11-02 0:00 ` Jon S Anthony 1996-11-03 0:00 ` Joachim Durchholz 1996-11-05 0:00 ` Norman H. Cohen 8 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-28 0:00 ` Matthew Heaney ` (6 preceding siblings ...) 1996-11-02 0:00 ` Eiffel and Java Jon S Anthony @ 1996-11-03 0:00 ` Joachim Durchholz 1996-11-05 0:00 ` Norman H. Cohen 8 siblings, 0 replies; 168+ messages in thread From: Joachim Durchholz @ 1996-11-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-28 0:00 ` Matthew Heaney ` (7 preceding siblings ...) 1996-11-03 0:00 ` Joachim Durchholz @ 1996-11-05 0:00 ` Norman H. Cohen 8 siblings, 0 replies; 168+ messages in thread From: Norman H. Cohen @ 1996-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 Eiffel and Java Vincent WEBER 1996-10-27 0:00 ` Jean-Michel P. Decombe 1996-10-28 0:00 ` Matthew Heaney @ 1996-10-28 0:00 ` Larry Kilgallen 1996-10-30 0:00 ` Ronald Cole 1996-10-29 0:00 ` Don Harrison ` (6 subsequent siblings) 9 siblings, 1 reply; 168+ messages in thread From: Larry Kilgallen @ 1996-10-28 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-28 0:00 ` Larry Kilgallen @ 1996-10-30 0:00 ` Ronald Cole 0 siblings, 0 replies; 168+ messages in thread From: Ronald Cole @ 1996-10-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 Eiffel and Java Vincent WEBER ` (2 preceding siblings ...) 1996-10-28 0:00 ` Larry Kilgallen @ 1996-10-29 0:00 ` Don Harrison 1996-10-29 0:00 ` Fergus Henderson ` (10 more replies) 1996-10-30 0:00 ` Jon S Anthony ` (5 subsequent siblings) 9 siblings, 11 replies; 168+ messages in thread From: Don Harrison @ 1996-10-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Don Harrison @ 1996-10-29 0:00 ` Fergus Henderson 1996-10-30 0:00 ` Don Harrison ` (7 more replies) 1996-10-29 0:00 ` Eiffel and Java + Ada dispatching Vincent WEBER ` (9 subsequent siblings) 10 siblings, 8 replies; 168+ messages in thread From: Fergus Henderson @ 1996-10-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Fergus Henderson @ 1996-10-30 0:00 ` Don Harrison 1996-10-30 0:00 ` Fergus Henderson 1996-10-31 0:00 ` David L. Shang ` (6 subsequent siblings) 7 siblings, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-10-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-30 0:00 ` Don Harrison @ 1996-10-30 0:00 ` Fergus Henderson 0 siblings, 0 replies; 168+ messages in thread From: Fergus Henderson @ 1996-10-30 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Fergus Henderson 1996-10-30 0:00 ` Don Harrison @ 1996-10-31 0:00 ` David L. Shang 1996-11-01 0:00 ` Matt Kennel 1996-11-04 0:00 ` Robert I. Eachus 1996-11-01 0:00 ` Jon S Anthony ` (5 subsequent siblings) 7 siblings, 2 replies; 168+ messages in thread From: David L. Shang @ 1996-10-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-31 0:00 ` David L. Shang @ 1996-11-01 0:00 ` Matt Kennel 1996-11-04 0:00 ` David L. Shang 1996-11-04 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 168+ messages in thread From: Matt Kennel @ 1996-11-01 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-01 0:00 ` Matt Kennel @ 1996-11-04 0:00 ` David L. Shang 1996-11-05 0:00 ` Matt Kennel 0 siblings, 1 reply; 168+ messages in thread From: David L. Shang @ 1996-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-04 0:00 ` David L. Shang @ 1996-11-05 0:00 ` Matt Kennel 1996-11-06 0:00 ` David L. Shang 0 siblings, 1 reply; 168+ messages in thread From: Matt Kennel @ 1996-11-05 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-05 0:00 ` Matt Kennel @ 1996-11-06 0:00 ` David L. Shang 0 siblings, 0 replies; 168+ messages in thread From: David L. Shang @ 1996-11-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-31 0:00 ` David L. Shang 1996-11-01 0:00 ` Matt Kennel @ 1996-11-04 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 168+ messages in thread From: Robert I. Eachus @ 1996-11-04 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Fergus Henderson 1996-10-30 0:00 ` Don Harrison 1996-10-31 0:00 ` David L. Shang @ 1996-11-01 0:00 ` Jon S Anthony 1996-11-02 0:00 ` Fergus Henderson 1996-11-04 0:00 ` David L. Shang 1996-11-02 0:00 ` Darko BUDOR ` (4 subsequent siblings) 7 siblings, 2 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-01 0:00 ` Jon S Anthony @ 1996-11-02 0:00 ` Fergus Henderson 1996-11-04 0:00 ` David L. Shang 1 sibling, 0 replies; 168+ messages in thread From: Fergus Henderson @ 1996-11-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-01 0:00 ` Jon S Anthony 1996-11-02 0:00 ` Fergus Henderson @ 1996-11-04 0:00 ` David L. Shang 1996-11-05 0:00 ` Jon S Anthony 1 sibling, 1 reply; 168+ messages in thread From: David L. Shang @ 1996-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-04 0:00 ` David L. Shang @ 1996-11-05 0:00 ` Jon S Anthony 0 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Fergus Henderson ` (2 preceding siblings ...) 1996-11-01 0:00 ` Jon S Anthony @ 1996-11-02 0:00 ` Darko BUDOR 1996-11-02 0:00 ` Fergus Henderson 1996-11-03 0:00 ` Matthias Ernst ` (3 subsequent siblings) 7 siblings, 1 reply; 168+ messages in thread From: Darko BUDOR @ 1996-11-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-02 0:00 ` Darko BUDOR @ 1996-11-02 0:00 ` Fergus Henderson 1996-11-03 0:00 ` Darko BUDOR 1996-11-03 0:00 ` Matt Kennel 0 siblings, 2 replies; 168+ messages in thread From: Fergus Henderson @ 1996-11-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-02 0:00 ` Fergus Henderson @ 1996-11-03 0:00 ` Darko BUDOR 1996-11-03 0:00 ` Matt Kennel 1 sibling, 0 replies; 168+ messages in thread From: Darko BUDOR @ 1996-11-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-02 0:00 ` Fergus Henderson 1996-11-03 0:00 ` Darko BUDOR @ 1996-11-03 0:00 ` Matt Kennel 1 sibling, 0 replies; 168+ messages in thread From: Matt Kennel @ 1996-11-03 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Fergus Henderson ` (3 preceding siblings ...) 1996-11-02 0:00 ` Darko BUDOR @ 1996-11-03 0:00 ` Matthias Ernst 1996-11-03 0:00 ` Jon S Anthony ` (2 subsequent siblings) 7 siblings, 0 replies; 168+ messages in thread From: Matthias Ernst @ 1996-11-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Fergus Henderson ` (4 preceding siblings ...) 1996-11-03 0:00 ` Matthias Ernst @ 1996-11-03 0:00 ` Jon S Anthony 1996-11-05 0:00 ` Jon S Anthony 1996-11-10 0:00 ` Marcos F. F. de Macedo 7 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Fergus Henderson ` (5 preceding siblings ...) 1996-11-03 0:00 ` Jon S Anthony @ 1996-11-05 0:00 ` Jon S Anthony 1996-11-10 0:00 ` Marcos F. F. de Macedo 7 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Fergus Henderson ` (6 preceding siblings ...) 1996-11-05 0:00 ` Jon S Anthony @ 1996-11-10 0:00 ` Marcos F. F. de Macedo 1996-11-11 0:00 ` David L. Shang 1996-11-12 0:00 ` Alexander Asteroth 7 siblings, 2 replies; 168+ messages in thread From: Marcos F. F. de Macedo @ 1996-11-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-10 0:00 ` Marcos F. F. de Macedo @ 1996-11-11 0:00 ` David L. Shang 1996-11-12 0:00 ` Fergus Henderson 1996-11-15 0:00 ` Paul Johnson 1996-11-12 0:00 ` Alexander Asteroth 1 sibling, 2 replies; 168+ messages in thread From: David L. Shang @ 1996-11-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-11 0:00 ` David L. Shang @ 1996-11-12 0:00 ` Fergus Henderson 1996-11-12 0:00 ` David L. Shang 1996-11-15 0:00 ` Paul Johnson 1 sibling, 1 reply; 168+ messages in thread From: Fergus Henderson @ 1996-11-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-12 0:00 ` Fergus Henderson @ 1996-11-12 0:00 ` David L. Shang 1996-11-12 0:00 ` David L. Shang ` (2 more replies) 0 siblings, 3 replies; 168+ messages in thread From: David L. Shang @ 1996-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-12 0:00 ` David L. Shang @ 1996-11-12 0:00 ` David L. Shang 1996-11-16 0:00 ` Fergus Henderson 1996-11-18 0:00 ` Kai Quale 2 siblings, 0 replies; 168+ messages in thread From: David L. Shang @ 1996-11-12 0:00 UTC (permalink / raw) 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 > ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-12 0:00 ` David L. Shang 1996-11-12 0:00 ` David L. Shang @ 1996-11-16 0:00 ` Fergus Henderson 1996-11-18 0:00 ` David L. Shang 1996-11-18 0:00 ` Kai Quale 2 siblings, 1 reply; 168+ messages in thread From: Fergus Henderson @ 1996-11-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-16 0:00 ` Fergus Henderson @ 1996-11-18 0:00 ` David L. Shang 0 siblings, 0 replies; 168+ messages in thread From: David L. Shang @ 1996-11-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-12 0:00 ` David L. Shang 1996-11-12 0:00 ` David L. Shang 1996-11-16 0:00 ` Fergus Henderson @ 1996-11-18 0:00 ` Kai Quale 1996-11-18 0:00 ` David L. Shang 2 siblings, 1 reply; 168+ messages in thread From: Kai Quale @ 1996-11-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-18 0:00 ` Kai Quale @ 1996-11-18 0:00 ` David L. Shang 1996-11-25 0:00 ` Kai Quale 0 siblings, 1 reply; 168+ messages in thread From: David L. Shang @ 1996-11-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-18 0:00 ` David L. Shang @ 1996-11-25 0:00 ` Kai Quale 0 siblings, 0 replies; 168+ messages in thread From: Kai Quale @ 1996-11-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-11 0:00 ` David L. Shang 1996-11-12 0:00 ` Fergus Henderson @ 1996-11-15 0:00 ` Paul Johnson 1 sibling, 0 replies; 168+ messages in thread From: Paul Johnson @ 1996-11-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-10 0:00 ` Marcos F. F. de Macedo 1996-11-11 0:00 ` David L. Shang @ 1996-11-12 0:00 ` Alexander Asteroth 1996-11-11 0:00 ` Marcos F. F. de Macedo ` (2 more replies) 1 sibling, 3 replies; 168+ messages in thread From: Alexander Asteroth @ 1996-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-12 0:00 ` Alexander Asteroth @ 1996-11-11 0:00 ` Marcos F. F. de Macedo 1996-11-12 0:00 ` Benedict A. Gomes 1996-11-12 0:00 ` Matt Kennel 2 siblings, 0 replies; 168+ messages in thread From: Marcos F. F. de Macedo @ 1996-11-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-12 0:00 ` Alexander Asteroth 1996-11-11 0:00 ` Marcos F. F. de Macedo @ 1996-11-12 0:00 ` Benedict A. Gomes 1996-11-12 0:00 ` Matt Kennel 2 siblings, 0 replies; 168+ messages in thread From: Benedict A. Gomes @ 1996-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-12 0:00 ` Alexander Asteroth 1996-11-11 0:00 ` Marcos F. F. de Macedo 1996-11-12 0:00 ` Benedict A. Gomes @ 1996-11-12 0:00 ` Matt Kennel 2 siblings, 0 replies; 168+ messages in thread From: Matt Kennel @ 1996-11-12 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-29 0:00 ` Don Harrison 1996-10-29 0:00 ` Fergus Henderson @ 1996-10-29 0:00 ` Vincent WEBER 1996-10-30 0:00 ` Don Harrison 1996-10-30 0:00 ` Jean-Marc Jezequel 1996-10-30 0:00 ` Robert I. Eachus ` (8 subsequent siblings) 10 siblings, 2 replies; 168+ messages in thread From: Vincent WEBER @ 1996-10-29 0:00 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-29 0:00 ` Eiffel and Java + Ada dispatching Vincent WEBER @ 1996-10-30 0:00 ` Don Harrison 1996-10-30 0:00 ` Jon S Anthony 1996-10-30 0:00 ` Jean-Marc Jezequel 1 sibling, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-10-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-30 0:00 ` Don Harrison @ 1996-10-30 0:00 ` Jon S Anthony 0 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-10-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-29 0:00 ` Eiffel and Java + Ada dispatching Vincent WEBER 1996-10-30 0:00 ` Don Harrison @ 1996-10-30 0:00 ` Jean-Marc Jezequel 1996-11-01 0:00 ` Joachim Durchholz 1996-11-01 0:00 ` Don Harrison 1 sibling, 2 replies; 168+ messages in thread From: Jean-Marc Jezequel @ 1996-10-30 0:00 UTC (permalink / raw) To: Vincent WEBER 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-30 0:00 ` Jean-Marc Jezequel @ 1996-11-01 0:00 ` Joachim Durchholz 1996-11-01 0:00 ` Don Harrison 1 sibling, 0 replies; 168+ messages in thread From: Joachim Durchholz @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-30 0:00 ` Jean-Marc Jezequel 1996-11-01 0:00 ` Joachim Durchholz @ 1996-11-01 0:00 ` Don Harrison 1 sibling, 0 replies; 168+ messages in thread From: Don Harrison @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-29 0:00 ` Don Harrison 1996-10-29 0:00 ` Fergus Henderson 1996-10-29 0:00 ` Eiffel and Java + Ada dispatching Vincent WEBER @ 1996-10-30 0:00 ` Robert I. Eachus 1996-10-30 0:00 ` Eiffel and Java David Petrie Stoutamire ` (7 subsequent siblings) 10 siblings, 0 replies; 168+ messages in thread From: Robert I. Eachus @ 1996-10-30 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Don Harrison ` (2 preceding siblings ...) 1996-10-30 0:00 ` Robert I. Eachus @ 1996-10-30 0:00 ` David Petrie Stoutamire 1996-10-30 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony ` (6 subsequent siblings) 10 siblings, 0 replies; 168+ messages in thread From: David Petrie Stoutamire @ 1996-10-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-29 0:00 ` Don Harrison ` (3 preceding siblings ...) 1996-10-30 0:00 ` Eiffel and Java David Petrie Stoutamire @ 1996-10-30 0:00 ` Jon S Anthony 1996-11-04 0:00 ` Don Harrison 1996-10-31 0:00 ` Jon S Anthony ` (5 subsequent siblings) 10 siblings, 1 reply; 168+ messages in thread From: Jon S Anthony @ 1996-10-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-30 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony @ 1996-11-04 0:00 ` Don Harrison 1996-11-04 0:00 ` C to Ada Ali Mirhosseini 1996-11-05 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony 0 siblings, 2 replies; 168+ messages in thread From: Don Harrison @ 1996-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* C to Ada 1996-11-04 0:00 ` Don Harrison @ 1996-11-04 0:00 ` Ali Mirhosseini 1996-11-04 0:00 ` Matthew Daniel 1996-11-04 0:00 ` Robert Dewar 1996-11-05 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony 1 sibling, 2 replies; 168+ messages in thread From: Ali Mirhosseini @ 1996-11-04 0:00 UTC (permalink / raw) 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 ----------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: C to Ada 1996-11-04 0:00 ` C to Ada Ali Mirhosseini @ 1996-11-04 0:00 ` Matthew Daniel 1996-11-04 0:00 ` Robert Dewar 1 sibling, 0 replies; 168+ messages in thread From: Matthew Daniel @ 1996-11-04 0:00 UTC (permalink / raw) To: Ali Mirhosseini 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: C to Ada 1996-11-04 0:00 ` C to Ada Ali Mirhosseini 1996-11-04 0:00 ` Matthew Daniel @ 1996-11-04 0:00 ` Robert Dewar 1 sibling, 0 replies; 168+ messages in thread From: Robert Dewar @ 1996-11-04 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-04 0:00 ` Don Harrison 1996-11-04 0:00 ` C to Ada Ali Mirhosseini @ 1996-11-05 0:00 ` Jon S Anthony 1996-11-05 0:00 ` Don Harrison 1 sibling, 1 reply; 168+ messages in thread From: Jon S Anthony @ 1996-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-05 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony @ 1996-11-05 0:00 ` Don Harrison 1996-11-06 0:00 ` Jon S Anthony 0 siblings, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-05 0:00 ` Don Harrison @ 1996-11-06 0:00 ` Jon S Anthony 0 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-29 0:00 ` Don Harrison ` (4 preceding siblings ...) 1996-10-30 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony @ 1996-10-31 0:00 ` Jon S Anthony 1996-11-01 0:00 ` Jean-Marc Jezequel [not found] ` <E06F2B.Az7@syd.csa.com.au> 1996-10-31 0:00 ` Joachim Durchholz ` (4 subsequent siblings) 10 siblings, 2 replies; 168+ messages in thread From: Jon S Anthony @ 1996-10-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-31 0:00 ` Jon S Anthony @ 1996-11-01 0:00 ` Jean-Marc Jezequel [not found] ` <E06F2B.Az7@syd.csa.com.au> 1 sibling, 0 replies; 168+ messages in thread From: Jean-Marc Jezequel @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
[parent not found: <E06F2B.Az7@syd.csa.com.au>]
* Re: Eiffel and Java + Ada dispatching [not found] ` <E06F2B.Az7@syd.csa.com.au> @ 1996-11-01 0:00 ` Jon S Anthony 1996-11-04 0:00 ` Don Harrison 1996-11-02 0:00 ` Robert Dewar 1 sibling, 1 reply; 168+ messages in thread From: Jon S Anthony @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-01 0:00 ` Jon S Anthony @ 1996-11-04 0:00 ` Don Harrison 1996-11-05 0:00 ` Jon S Anthony 0 siblings, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-04 0:00 ` Don Harrison @ 1996-11-05 0:00 ` Jon S Anthony 0 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching [not found] ` <E06F2B.Az7@syd.csa.com.au> 1996-11-01 0:00 ` Jon S Anthony @ 1996-11-02 0:00 ` Robert Dewar 1996-11-04 0:00 ` Norman H. Cohen 1996-11-05 0:00 ` Don Harrison 1 sibling, 2 replies; 168+ messages in thread From: Robert Dewar @ 1996-11-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-02 0:00 ` Robert Dewar @ 1996-11-04 0:00 ` Norman H. Cohen 1996-11-05 0:00 ` Don Harrison 1 sibling, 0 replies; 168+ messages in thread From: Norman H. Cohen @ 1996-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-02 0:00 ` Robert Dewar 1996-11-04 0:00 ` Norman H. Cohen @ 1996-11-05 0:00 ` Don Harrison 1996-11-05 0:00 ` Joachim Durchholz ` (5 more replies) 1 sibling, 6 replies; 168+ messages in thread From: Don Harrison @ 1996-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-05 0:00 ` Don Harrison @ 1996-11-05 0:00 ` Joachim Durchholz 1996-11-05 0:00 ` Robb Nebbe ` (4 subsequent siblings) 5 siblings, 0 replies; 168+ messages in thread From: Joachim Durchholz @ 1996-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-05 0:00 ` Don Harrison 1996-11-05 0:00 ` Joachim Durchholz @ 1996-11-05 0:00 ` Robb Nebbe 1996-11-06 0:00 ` Jean-Marc Jezequel ` (2 more replies) 1996-11-06 0:00 ` Robert I. Eachus ` (3 subsequent siblings) 5 siblings, 3 replies; 168+ messages in thread From: Robb Nebbe @ 1996-11-05 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-05 0:00 ` Robb Nebbe @ 1996-11-06 0:00 ` Jean-Marc Jezequel 1996-11-07 0:00 ` Robb Nebbe 1996-11-06 0:00 ` To overload or not to overload (was Eiffel and Java + Ada dispatching) Don Harrison 1996-11-08 0:00 ` Eiffel and Java + Ada dispatching Robert I. Eachus 2 siblings, 1 reply; 168+ messages in thread From: Jean-Marc Jezequel @ 1996-11-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-06 0:00 ` Jean-Marc Jezequel @ 1996-11-07 0:00 ` Robb Nebbe 0 siblings, 0 replies; 168+ messages in thread From: Robb Nebbe @ 1996-11-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-05 0:00 ` Robb Nebbe 1996-11-06 0:00 ` Jean-Marc Jezequel @ 1996-11-06 0:00 ` Don Harrison 1996-11-06 0:00 ` Robb Nebbe 1996-11-08 0:00 ` Eiffel and Java + Ada dispatching Robert I. Eachus 2 siblings, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-11-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-06 0:00 ` To overload or not to overload (was Eiffel and Java + Ada dispatching) Don Harrison @ 1996-11-06 0:00 ` Robb Nebbe 1996-11-07 0:00 ` Norman H. Cohen 1996-11-07 0:00 ` Don Harrison 0 siblings, 2 replies; 168+ messages in thread From: Robb Nebbe @ 1996-11-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-06 0:00 ` Robb Nebbe @ 1996-11-07 0:00 ` Norman H. Cohen 1996-11-07 0:00 ` Don Harrison 1 sibling, 0 replies; 168+ messages in thread From: Norman H. Cohen @ 1996-11-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-06 0:00 ` Robb Nebbe 1996-11-07 0:00 ` Norman H. Cohen @ 1996-11-07 0:00 ` Don Harrison 1996-11-07 0:00 ` Jon S Anthony ` (3 more replies) 1 sibling, 4 replies; 168+ messages in thread From: Don Harrison @ 1996-11-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-07 0:00 ` Don Harrison @ 1996-11-07 0:00 ` Jon S Anthony 1996-11-07 0:00 ` Juergen Schlegelmilch ` (2 subsequent siblings) 3 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-07 0:00 ` Don Harrison 1996-11-07 0:00 ` Jon S Anthony @ 1996-11-07 0:00 ` Juergen Schlegelmilch 1996-11-08 0:00 ` Don Harrison 1996-11-14 0:00 ` Jon S Anthony 1996-11-07 0:00 ` Jon S Anthony 1996-11-08 0:00 ` bill.williams 3 siblings, 2 replies; 168+ messages in thread From: Juergen Schlegelmilch @ 1996-11-07 0:00 UTC (permalink / raw) 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 +-----------------------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-07 0:00 ` Juergen Schlegelmilch @ 1996-11-08 0:00 ` Don Harrison 1996-11-08 0:00 ` Don Harrison 1996-11-14 0:00 ` Jon S Anthony 1 sibling, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-11-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-08 0:00 ` Don Harrison @ 1996-11-08 0:00 ` Don Harrison 1996-11-14 0:00 ` Jon S Anthony 0 siblings, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-11-08 0:00 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-08 0:00 ` Don Harrison @ 1996-11-14 0:00 ` Jon S Anthony 0 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-07 0:00 ` Juergen Schlegelmilch 1996-11-08 0:00 ` Don Harrison @ 1996-11-14 0:00 ` Jon S Anthony 1 sibling, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-07 0:00 ` Don Harrison 1996-11-07 0:00 ` Jon S Anthony 1996-11-07 0:00 ` Juergen Schlegelmilch @ 1996-11-07 0:00 ` Jon S Anthony 1996-11-11 0:00 ` Don Harrison 1996-11-08 0:00 ` bill.williams 3 siblings, 1 reply; 168+ messages in thread From: Jon S Anthony @ 1996-11-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-07 0:00 ` Jon S Anthony @ 1996-11-11 0:00 ` Don Harrison 0 siblings, 0 replies; 168+ messages in thread From: Don Harrison @ 1996-11-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-07 0:00 ` Don Harrison ` (2 preceding siblings ...) 1996-11-07 0:00 ` Jon S Anthony @ 1996-11-08 0:00 ` bill.williams 1996-11-11 0:00 ` Don Harrison 3 siblings, 1 reply; 168+ messages in thread From: bill.williams @ 1996-11-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) 1996-11-08 0:00 ` bill.williams @ 1996-11-11 0:00 ` Don Harrison 0 siblings, 0 replies; 168+ messages in thread From: Don Harrison @ 1996-11-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-05 0:00 ` Robb Nebbe 1996-11-06 0:00 ` Jean-Marc Jezequel 1996-11-06 0:00 ` To overload or not to overload (was Eiffel and Java + Ada dispatching) Don Harrison @ 1996-11-08 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 168+ messages in thread From: Robert I. Eachus @ 1996-11-08 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-05 0:00 ` Don Harrison 1996-11-05 0:00 ` Joachim Durchholz 1996-11-05 0:00 ` Robb Nebbe @ 1996-11-06 0:00 ` Robert I. Eachus 1996-11-08 0:00 ` Don Harrison 1996-11-07 0:00 ` Eiffel and Java + Ada dispatching Robb Nebbe ` (2 subsequent siblings) 5 siblings, 1 reply; 168+ messages in thread From: Robert I. Eachus @ 1996-11-06 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-06 0:00 ` Robert I. Eachus @ 1996-11-08 0:00 ` Don Harrison 1996-11-08 0:00 ` Jon S Anthony ` (3 more replies) 0 siblings, 4 replies; 168+ messages in thread From: Don Harrison @ 1996-11-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-08 0:00 ` Don Harrison @ 1996-11-08 0:00 ` Jon S Anthony 1996-11-08 0:00 ` Robert A Duff ` (2 subsequent siblings) 3 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-08 0:00 ` Don Harrison 1996-11-08 0:00 ` Jon S Anthony @ 1996-11-08 0:00 ` Robert A Duff 1996-11-12 0:00 ` Don Harrison 1996-11-14 0:00 ` Eiffel and Java + Ada dispatching Robert I. Eachus 1996-11-15 0:00 ` portmanteau (was Re: Eiffel and Java + Ada dispatching) Robert I. Eachus 3 siblings, 1 reply; 168+ messages in thread From: Robert A Duff @ 1996-11-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-08 0:00 ` Robert A Duff @ 1996-11-12 0:00 ` Don Harrison 1996-11-12 0:00 ` Robert A Duff 1996-11-12 0:00 ` Joachim Durchholz 0 siblings, 2 replies; 168+ messages in thread From: Don Harrison @ 1996-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-12 0:00 ` Don Harrison @ 1996-11-12 0:00 ` Robert A Duff 1996-11-13 0:00 ` Don Harrison 1996-11-12 0:00 ` Joachim Durchholz 1 sibling, 1 reply; 168+ messages in thread From: Robert A Duff @ 1996-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-12 0:00 ` Robert A Duff @ 1996-11-13 0:00 ` Don Harrison 1996-11-13 0:00 ` Jon S Anthony 1996-11-13 0:00 ` Robert A Duff 0 siblings, 2 replies; 168+ messages in thread From: Don Harrison @ 1996-11-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-13 0:00 ` Don Harrison @ 1996-11-13 0:00 ` Jon S Anthony 1996-11-15 0:00 ` Don Harrison 1996-11-13 0:00 ` Robert A Duff 1 sibling, 1 reply; 168+ messages in thread From: Jon S Anthony @ 1996-11-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-13 0:00 ` Jon S Anthony @ 1996-11-15 0:00 ` Don Harrison 1996-11-19 0:00 ` Jon S Anthony 0 siblings, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-11-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-15 0:00 ` Don Harrison @ 1996-11-19 0:00 ` Jon S Anthony 1996-11-20 0:00 ` Don Harrison 0 siblings, 1 reply; 168+ messages in thread From: Jon S Anthony @ 1996-11-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-19 0:00 ` Jon S Anthony @ 1996-11-20 0:00 ` Don Harrison 0 siblings, 0 replies; 168+ messages in thread From: Don Harrison @ 1996-11-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-13 0:00 ` Don Harrison 1996-11-13 0:00 ` Jon S Anthony @ 1996-11-13 0:00 ` Robert A Duff 1996-11-14 0:00 ` Don Harrison 1 sibling, 1 reply; 168+ messages in thread From: Robert A Duff @ 1996-11-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-13 0:00 ` Robert A Duff @ 1996-11-14 0:00 ` Don Harrison 0 siblings, 0 replies; 168+ messages in thread From: Don Harrison @ 1996-11-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-12 0:00 ` Don Harrison 1996-11-12 0:00 ` Robert A Duff @ 1996-11-12 0:00 ` Joachim Durchholz 1996-11-15 0:00 ` Richard Riehle 1996-11-16 0:00 ` Interfacing contracts (Was: Eiffel and Java + Ada dispatching) Geert Bosch 1 sibling, 2 replies; 168+ messages in thread From: Joachim Durchholz @ 1996-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-12 0:00 ` Joachim Durchholz @ 1996-11-15 0:00 ` Richard Riehle 1996-11-16 0:00 ` Interfacing contracts (Was: Eiffel and Java + Ada dispatching) Geert Bosch 1 sibling, 0 replies; 168+ messages in thread From: Richard Riehle @ 1996-11-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Interfacing contracts (Was: Eiffel and Java + Ada dispatching) 1996-11-12 0:00 ` Joachim Durchholz 1996-11-15 0:00 ` Richard Riehle @ 1996-11-16 0:00 ` Geert Bosch 1996-11-17 0:00 ` Robert A Duff 1 sibling, 1 reply; 168+ messages in thread From: Geert Bosch @ 1996-11-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Interfacing contracts (Was: Eiffel and Java + Ada dispatching) 1996-11-16 0:00 ` Interfacing contracts (Was: Eiffel and Java + Ada dispatching) Geert Bosch @ 1996-11-17 0:00 ` Robert A Duff 0 siblings, 0 replies; 168+ messages in thread From: Robert A Duff @ 1996-11-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-08 0:00 ` Don Harrison 1996-11-08 0:00 ` Jon S Anthony 1996-11-08 0:00 ` Robert A Duff @ 1996-11-14 0:00 ` Robert I. Eachus 1996-11-14 0:00 ` Robert A Duff ` (2 more replies) 1996-11-15 0:00 ` portmanteau (was Re: Eiffel and Java + Ada dispatching) Robert I. Eachus 3 siblings, 3 replies; 168+ messages in thread From: Robert I. Eachus @ 1996-11-14 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-14 0:00 ` Eiffel and Java + Ada dispatching Robert I. Eachus @ 1996-11-14 0:00 ` Robert A Duff 1996-11-15 0:00 ` Don Harrison 1996-11-19 0:00 ` Jon S Anthony 2 siblings, 0 replies; 168+ messages in thread From: Robert A Duff @ 1996-11-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-14 0:00 ` Eiffel and Java + Ada dispatching Robert I. Eachus 1996-11-14 0:00 ` Robert A Duff @ 1996-11-15 0:00 ` Don Harrison 1996-11-15 0:00 ` Robert I. Eachus 1996-11-19 0:00 ` Jon S Anthony 2 siblings, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-11-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-15 0:00 ` Don Harrison @ 1996-11-15 0:00 ` Robert I. Eachus 1996-11-19 0:00 ` Don Harrison 0 siblings, 1 reply; 168+ messages in thread From: Robert I. Eachus @ 1996-11-15 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-15 0:00 ` Robert I. Eachus @ 1996-11-19 0:00 ` Don Harrison 1996-11-18 0:00 ` Vincent Celier 0 siblings, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-11-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-19 0:00 ` Don Harrison @ 1996-11-18 0:00 ` Vincent Celier 1996-11-22 0:00 ` Don Harrison 0 siblings, 1 reply; 168+ messages in thread From: Vincent Celier @ 1996-11-18 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-18 0:00 ` Vincent Celier @ 1996-11-22 0:00 ` Don Harrison 0 siblings, 0 replies; 168+ messages in thread From: Don Harrison @ 1996-11-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-14 0:00 ` Eiffel and Java + Ada dispatching Robert I. Eachus 1996-11-14 0:00 ` Robert A Duff 1996-11-15 0:00 ` Don Harrison @ 1996-11-19 0:00 ` Jon S Anthony 2 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: portmanteau (was Re: Eiffel and Java + Ada dispatching) 1996-11-08 0:00 ` Don Harrison ` (2 preceding siblings ...) 1996-11-14 0:00 ` Eiffel and Java + Ada dispatching Robert I. Eachus @ 1996-11-15 0:00 ` Robert I. Eachus 3 siblings, 0 replies; 168+ messages in thread From: Robert I. Eachus @ 1996-11-15 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-05 0:00 ` Don Harrison ` (2 preceding siblings ...) 1996-11-06 0:00 ` Robert I. Eachus @ 1996-11-07 0:00 ` Robb Nebbe 1996-11-07 0:00 ` Jon S Anthony 1996-11-12 0:00 ` Jon S Anthony 5 siblings, 0 replies; 168+ messages in thread From: Robb Nebbe @ 1996-11-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-05 0:00 ` Don Harrison ` (3 preceding siblings ...) 1996-11-07 0:00 ` Eiffel and Java + Ada dispatching Robb Nebbe @ 1996-11-07 0:00 ` Jon S Anthony 1996-11-12 0:00 ` Jon S Anthony 5 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-11-05 0:00 ` Don Harrison ` (4 preceding siblings ...) 1996-11-07 0:00 ` Jon S Anthony @ 1996-11-12 0:00 ` Jon S Anthony 5 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-29 0:00 ` Don Harrison ` (5 preceding siblings ...) 1996-10-31 0:00 ` Jon S Anthony @ 1996-10-31 0:00 ` Joachim Durchholz 1996-11-01 0:00 ` Eiffel and Java Matthias Ernst ` (3 subsequent siblings) 10 siblings, 0 replies; 168+ messages in thread From: Joachim Durchholz @ 1996-10-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Don Harrison ` (6 preceding siblings ...) 1996-10-31 0:00 ` Joachim Durchholz @ 1996-11-01 0:00 ` Matthias Ernst 1996-11-01 0:00 ` William Clodius 1996-11-01 0:00 ` Benedict A. Gomes 1996-11-02 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony ` (2 subsequent siblings) 10 siblings, 2 replies; 168+ messages in thread From: Matthias Ernst @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-01 0:00 ` Eiffel and Java Matthias Ernst @ 1996-11-01 0:00 ` William Clodius 1996-11-01 0:00 ` Benedict A. Gomes 1 sibling, 0 replies; 168+ messages in thread From: William Clodius @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-01 0:00 ` Eiffel and Java Matthias Ernst 1996-11-01 0:00 ` William Clodius @ 1996-11-01 0:00 ` Benedict A. Gomes 1 sibling, 0 replies; 168+ messages in thread From: Benedict A. Gomes @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-29 0:00 ` Don Harrison ` (7 preceding siblings ...) 1996-11-01 0:00 ` Eiffel and Java Matthias Ernst @ 1996-11-02 0:00 ` Jon S Anthony 1996-11-02 0:00 ` Jon S Anthony 1996-11-04 0:00 ` Eiffel and Java Robert I. Eachus 10 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-29 0:00 ` Don Harrison ` (8 preceding siblings ...) 1996-11-02 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony @ 1996-11-02 0:00 ` Jon S Anthony 1996-11-04 0:00 ` Eiffel and Java Robert I. Eachus 10 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-29 0:00 ` Don Harrison ` (9 preceding siblings ...) 1996-11-02 0:00 ` Jon S Anthony @ 1996-11-04 0:00 ` Robert I. Eachus 10 siblings, 0 replies; 168+ messages in thread From: Robert I. Eachus @ 1996-11-04 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 Eiffel and Java Vincent WEBER ` (3 preceding siblings ...) 1996-10-29 0:00 ` Don Harrison @ 1996-10-30 0:00 ` Jon S Anthony 1996-11-01 0:00 ` Don Harrison 1996-10-31 0:00 ` Joachim Durchholz ` (4 subsequent siblings) 9 siblings, 1 reply; 168+ messages in thread From: Jon S Anthony @ 1996-10-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-30 0:00 ` Jon S Anthony @ 1996-11-01 0:00 ` Don Harrison 1996-11-01 0:00 ` Jon S Anthony 1996-11-12 0:00 ` Jon S Anthony 0 siblings, 2 replies; 168+ messages in thread From: Don Harrison @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-01 0:00 ` Don Harrison @ 1996-11-01 0:00 ` Jon S Anthony 1996-11-07 0:00 ` Marcos F. F. de Macedo 1996-11-12 0:00 ` Jon S Anthony 1 sibling, 1 reply; 168+ messages in thread From: Jon S Anthony @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-01 0:00 ` Jon S Anthony @ 1996-11-07 0:00 ` Marcos F. F. de Macedo 1996-11-11 0:00 ` Ian Joyner 1996-11-12 0:00 ` Don Harrison 0 siblings, 2 replies; 168+ messages in thread From: Marcos F. F. de Macedo @ 1996-11-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-07 0:00 ` Marcos F. F. de Macedo @ 1996-11-11 0:00 ` Ian Joyner 1996-11-12 0:00 ` Don Harrison 1 sibling, 0 replies; 168+ messages in thread From: Ian Joyner @ 1996-11-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-07 0:00 ` Marcos F. F. de Macedo 1996-11-11 0:00 ` Ian Joyner @ 1996-11-12 0:00 ` Don Harrison 1996-11-13 0:00 ` Norman H. Cohen 1996-11-14 0:00 ` Jon S Anthony 1 sibling, 2 replies; 168+ messages in thread From: Don Harrison @ 1996-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-12 0:00 ` Don Harrison @ 1996-11-13 0:00 ` Norman H. Cohen 1996-11-15 0:00 ` Don Harrison 1996-11-14 0:00 ` Jon S Anthony 1 sibling, 1 reply; 168+ messages in thread From: Norman H. Cohen @ 1996-11-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-13 0:00 ` Norman H. Cohen @ 1996-11-15 0:00 ` Don Harrison 0 siblings, 0 replies; 168+ messages in thread From: Don Harrison @ 1996-11-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-12 0:00 ` Don Harrison 1996-11-13 0:00 ` Norman H. Cohen @ 1996-11-14 0:00 ` Jon S Anthony 1996-11-15 0:00 ` Don Harrison 1 sibling, 1 reply; 168+ messages in thread From: Jon S Anthony @ 1996-11-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-14 0:00 ` Jon S Anthony @ 1996-11-15 0:00 ` Don Harrison 1996-11-19 0:00 ` Jon S Anthony 0 siblings, 1 reply; 168+ messages in thread From: Don Harrison @ 1996-11-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-15 0:00 ` Don Harrison @ 1996-11-19 0:00 ` Jon S Anthony 1996-11-21 0:00 ` Don Harrison 0 siblings, 1 reply; 168+ messages in thread From: Jon S Anthony @ 1996-11-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-19 0:00 ` Jon S Anthony @ 1996-11-21 0:00 ` Don Harrison 0 siblings, 0 replies; 168+ messages in thread From: Don Harrison @ 1996-11-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-01 0:00 ` Don Harrison 1996-11-01 0:00 ` Jon S Anthony @ 1996-11-12 0:00 ` Jon S Anthony 1 sibling, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 Eiffel and Java Vincent WEBER ` (4 preceding siblings ...) 1996-10-30 0:00 ` Jon S Anthony @ 1996-10-31 0:00 ` Joachim Durchholz 1996-11-01 0:00 ` Jon S Anthony ` (3 subsequent siblings) 9 siblings, 0 replies; 168+ messages in thread From: Joachim Durchholz @ 1996-10-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 Eiffel and Java Vincent WEBER ` (5 preceding siblings ...) 1996-10-31 0:00 ` Joachim Durchholz @ 1996-11-01 0:00 ` Jon S Anthony 1996-11-02 0:00 ` Jon S Anthony ` (2 subsequent siblings) 9 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 Eiffel and Java Vincent WEBER ` (6 preceding siblings ...) 1996-11-01 0:00 ` Jon S Anthony @ 1996-11-02 0:00 ` Jon S Anthony 1996-11-03 0:00 ` Eiffel and Java + Ada dispatching Joachim Durchholz 1996-11-04 0:00 ` Eiffel and Java Richard A. O'Keefe 9 siblings, 0 replies; 168+ messages in thread From: Jon S Anthony @ 1996-11-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java + Ada dispatching 1996-10-27 0:00 Eiffel and Java Vincent WEBER ` (7 preceding siblings ...) 1996-11-02 0:00 ` Jon S Anthony @ 1996-11-03 0:00 ` Joachim Durchholz 1996-11-04 0:00 ` Eiffel and Java Richard A. O'Keefe 9 siblings, 0 replies; 168+ messages in thread From: Joachim Durchholz @ 1996-11-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-10-27 0:00 Eiffel and Java Vincent WEBER ` (8 preceding siblings ...) 1996-11-03 0:00 ` Eiffel and Java + Ada dispatching Joachim Durchholz @ 1996-11-04 0:00 ` Richard A. O'Keefe 9 siblings, 0 replies; 168+ messages in thread From: Richard A. O'Keefe @ 1996-11-04 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java @ 1996-10-28 0:00 cosc19z5@bayou.uh.edu [not found] ` <01bbc7f6$b1c0b7a0$LocalHost@gaijin> 0 siblings, 1 reply; 168+ messages in thread From: cosc19z5@bayou.uh.edu @ 1996-10-28 0:00 UTC (permalink / raw) Jean-Michel P. Decombe (xelph@acm.org) wrote: : In article <550sm2$sn1@buggy.news.easynet.net>, Sacha@easynet.fr (Vincent : WEBER) wrote: : > different). So... Why don't Eiffel and Java merge ?? Maybe it would be a grat : I believe that Java is not the death of other languages. Java demonstrates : that it's possible to write a language which is really : platform-independent and "distributed". Nothing prevents Meyer from : writing a new version of Eiffel, totally portable and based on a Virtual : Machine, then port this VM on a large number of platforms, including a : JITC, etc. With the promise of a true platform-independent language, I'm : sure a good number of people would be willing to try it, including myself. Well in a way this has been done. Java is valuable not for the "language" but rather for the virtual machine, and as it stands other languages are taking the cue, and are translating themselves into Java Bytecode so you can in fact do the same sort of platform independent programming that you can do in Java in other languages like Ada, and Smalltalk! So even with Java as the so-called king, this won't mean the death of other languages, even in distributed applications, since all that's needed is to translate the source into Java bytecode. : The only problem that remains would be a possible inclusion of this VM in : major browsers. But I believe most browsers will become very customizable : and won't be restricted to Java in the future, plus they will eventually : merge in the OS anyway... Even with browsers using the Java VM this only means that other languages need to output Java VM code. : Java is just the beginning of a new era, but it's certainly not the : language who will necessarily win in the end. For now, it's the only one : to do what it does, thus it's the "current" winner... It's just Java bytecode that's doing this, the language itself is can be changed to whatever is needed and it's being done already. : Xelph : ___________________________________________ : geo:1705 Cowper Street, Palo Alto, CA 94301 : phone:415/327-9563 - fax:415/327-3328 : mailto:xelph@acm.org - http://xelph.com/ Ahmed ^ permalink raw reply [flat|nested] 168+ messages in thread
[parent not found: <01bbc7f6$b1c0b7a0$LocalHost@gaijin>]
* Re: Eiffel and Java [not found] ` <01bbc7f6$b1c0b7a0$LocalHost@gaijin> @ 1996-11-01 0:00 ` Ranjan Bagchi 1996-11-01 0:00 ` Alan Lovejoy 1 sibling, 0 replies; 168+ messages in thread From: Ranjan Bagchi @ 1996-11-01 0:00 UTC (permalink / raw) Chris wrote: > > The point with Java is that it's nearly C++. > > So, even if it's not the best language, the C++ community would choose it > > That's enough to make it a standard ! > > Chris Note: Smalltalk bias. I'd think that this kind standard would tend to produce a lot of Java code which is just "C++ written in Java". That is C++ code with whatever syntactic tweaking is needed to get it pass the compiler. This is similar to what has happened in the C++ community where the joke was that there were only 5 real C++ programmers and everyone else was just coding C. There wasn't enough incentive to use the kind of C++ idioms that Coplien and Myers write about in their books. That's what's really neat about languages like Smalltalk where the language forces programmers to start thinking in Smalltalk's object model and produce Smalltalk written in Smalltalk. -rj ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java [not found] ` <01bbc7f6$b1c0b7a0$LocalHost@gaijin> 1996-11-01 0:00 ` Ranjan Bagchi @ 1996-11-01 0:00 ` Alan Lovejoy 1996-11-01 0:00 ` Chris 1 sibling, 1 reply; 168+ messages in thread From: Alan Lovejoy @ 1996-11-01 0:00 UTC (permalink / raw) Chris wrote: > > The point with Java is that it's nearly C++. > > So, even if it's not the best language, the C++ community would choose it But it won't kill off or significantly hurt other languages. Java is a big threat to the market share of C++, partly because it panders to the prejudices of C++ coders, and partly because it is a better business programming language than C++ (which is a better systems programming language than Java). C++ and C are both systems programming language that are widely used for business programming, a niche for which they are not ideal. Other languages are not so vulnerable, because they are not so widely used for a purpose for which they were not designed, and because their practitioners won't be seduced by the fact that Java is so similar to C++. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-01 0:00 ` Alan Lovejoy @ 1996-11-01 0:00 ` Chris 0 siblings, 0 replies; 168+ messages in thread From: Chris @ 1996-11-01 0:00 UTC (permalink / raw) > they are not ideal. Other languages are not so vulnerable, because they are not so > widely used for a purpose for which they were not designed, and because their > practitioners won't be seduced by the fact that Java is so similar to C++. > But *I* am ! Chris ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java @ 1996-11-02 0:00 Ell 1996-11-02 0:00 ` traymond 0 siblings, 1 reply; 168+ messages in thread From: Ell @ 1996-11-02 0:00 UTC (permalink / raw) Ranjan Bagchi (ranjan.bagchi@pobox.com) wrote: : Chris wrote: : > : > The point with Java is that it's nearly C++. : > : > So, even if it's not the best language, the C++ community would choose it : > : > That's enough to make it a standard ! : > : > Chris : Note: Smalltalk bias. : : I'd think that this kind standard would tend to produce a lot of Java : code which is just "C++ written in Java". That is C++ code with : whatever syntactic tweaking is needed to get it pass the compiler. And there are large amounts of fully object-oriented C++, just as there are other forms of C++ code. I.e. there is much C++ code which models in an OO way, and which uses OO design techniques to reduce dependencies. : This is similar to what has happened in the C++ community where the joke : was that there were only 5 real C++ programmers and everyone else was : just coding C. There wasn't enough incentive to use the kind of C++ : idioms that Coplien and Myers write about in their books. : : That's what's really neat about languages like Smalltalk where : the language forces programmers to start thinking in Smalltalk's object : model and produce Smalltalk written in Smalltalk. Isn't it possible for someone to write a Smalltalk program with bad design decompostion from an OO perspective? Elliott ^ permalink raw reply [flat|nested] 168+ messages in thread
* Re: Eiffel and Java 1996-11-02 0:00 Ell @ 1996-11-02 0:00 ` traymond 0 siblings, 0 replies; 168+ messages in thread From: traymond @ 1996-11-02 0:00 UTC (permalink / raw) In <55e611$abq@news3.digex.net>, ell@access4.digex.net (Ell) writes: >Ranjan Bagchi (ranjan.bagchi@pobox.com) wrote: >: That's what's really neat about languages like Smalltalk where >: the language forces programmers to start thinking in Smalltalk's object >: model and produce Smalltalk written in Smalltalk. > >Isn't it possible for someone to write a Smalltalk program with bad design >decompostion from an OO perspective? > >Elliott Sure it's possible to write poor programs in any language. However, it is harder to write non-oo code in Smalltalk than C++. Furthermore, because most Smalltalk environments have large libraries that include source code, novice Smalltalk programmers have easy access to good examples to assist in their learning. =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk *Breakpoints* and *Watchpoints* for 19 Tilley Ave. VW and Envy Newport, RI 02840 (401) 846-6573 traymond@craftedsmalltalk.com http://www.craftedsmalltalk.com =========================================================== ^ permalink raw reply [flat|nested] 168+ messages in thread
end of thread, other threads:[~1996-11-25 0:00 UTC | newest] Thread overview: 168+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-10-27 0:00 Eiffel and Java Vincent WEBER 1996-10-27 0:00 ` Jean-Michel P. Decombe 1996-10-28 0:00 ` David Hanley 1996-10-28 0:00 ` Matt Kennel 1996-10-28 0:00 ` Alexandre Oliva 1996-10-28 0:00 ` Robert Dewar 1996-10-31 0:00 ` Doug Marker 1996-10-29 0:00 ` Chris Trimble 1996-10-31 0:00 ` Doug Marker 1996-10-31 0:00 ` David Bennett 1996-10-28 0:00 ` Matthew Heaney 1996-10-29 0:00 ` Vincent WEBER 1996-10-31 0:00 ` James McKim 1996-11-01 0:00 ` Matthew Heaney 1996-11-04 0:00 ` James McKim 1996-10-30 0:00 ` Jon S Anthony 1996-11-01 0:00 ` Eiffel and Java + Ada dispatching Jean-Marc Jezequel 1996-10-30 0:00 ` Eiffel and Java Don Harrison 1996-10-31 0:00 ` James McKim 1996-11-04 0:00 ` Don Harrison 1996-11-23 0:00 ` Van Snyder 1996-10-31 0:00 ` Joachim Durchholz 1996-11-01 0:00 ` Norman H. Cohen 1996-11-02 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony 1996-11-02 0:00 ` Eiffel and Java Jon S Anthony 1996-11-03 0:00 ` Joachim Durchholz 1996-11-05 0:00 ` Norman H. Cohen 1996-10-28 0:00 ` Larry Kilgallen 1996-10-30 0:00 ` Ronald Cole 1996-10-29 0:00 ` Don Harrison 1996-10-29 0:00 ` Fergus Henderson 1996-10-30 0:00 ` Don Harrison 1996-10-30 0:00 ` Fergus Henderson 1996-10-31 0:00 ` David L. Shang 1996-11-01 0:00 ` Matt Kennel 1996-11-04 0:00 ` David L. Shang 1996-11-05 0:00 ` Matt Kennel 1996-11-06 0:00 ` David L. Shang 1996-11-04 0:00 ` Robert I. Eachus 1996-11-01 0:00 ` Jon S Anthony 1996-11-02 0:00 ` Fergus Henderson 1996-11-04 0:00 ` David L. Shang 1996-11-05 0:00 ` Jon S Anthony 1996-11-02 0:00 ` Darko BUDOR 1996-11-02 0:00 ` Fergus Henderson 1996-11-03 0:00 ` Darko BUDOR 1996-11-03 0:00 ` Matt Kennel 1996-11-03 0:00 ` Matthias Ernst 1996-11-03 0:00 ` Jon S Anthony 1996-11-05 0:00 ` Jon S Anthony 1996-11-10 0:00 ` Marcos F. F. de Macedo 1996-11-11 0:00 ` David L. Shang 1996-11-12 0:00 ` Fergus Henderson 1996-11-12 0:00 ` David L. Shang 1996-11-12 0:00 ` David L. Shang 1996-11-16 0:00 ` Fergus Henderson 1996-11-18 0:00 ` David L. Shang 1996-11-18 0:00 ` Kai Quale 1996-11-18 0:00 ` David L. Shang 1996-11-25 0:00 ` Kai Quale 1996-11-15 0:00 ` Paul Johnson 1996-11-12 0:00 ` Alexander Asteroth 1996-11-11 0:00 ` Marcos F. F. de Macedo 1996-11-12 0:00 ` Benedict A. Gomes 1996-11-12 0:00 ` Matt Kennel 1996-10-29 0:00 ` Eiffel and Java + Ada dispatching Vincent WEBER 1996-10-30 0:00 ` Don Harrison 1996-10-30 0:00 ` Jon S Anthony 1996-10-30 0:00 ` Jean-Marc Jezequel 1996-11-01 0:00 ` Joachim Durchholz 1996-11-01 0:00 ` Don Harrison 1996-10-30 0:00 ` Robert I. Eachus 1996-10-30 0:00 ` Eiffel and Java David Petrie Stoutamire 1996-10-30 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony 1996-11-04 0:00 ` Don Harrison 1996-11-04 0:00 ` C to Ada Ali Mirhosseini 1996-11-04 0:00 ` Matthew Daniel 1996-11-04 0:00 ` Robert Dewar 1996-11-05 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony 1996-11-05 0:00 ` Don Harrison 1996-11-06 0:00 ` Jon S Anthony 1996-10-31 0:00 ` Jon S Anthony 1996-11-01 0:00 ` Jean-Marc Jezequel [not found] ` <E06F2B.Az7@syd.csa.com.au> 1996-11-01 0:00 ` Jon S Anthony 1996-11-04 0:00 ` Don Harrison 1996-11-05 0:00 ` Jon S Anthony 1996-11-02 0:00 ` Robert Dewar 1996-11-04 0:00 ` Norman H. Cohen 1996-11-05 0:00 ` Don Harrison 1996-11-05 0:00 ` Joachim Durchholz 1996-11-05 0:00 ` Robb Nebbe 1996-11-06 0:00 ` Jean-Marc Jezequel 1996-11-07 0:00 ` Robb Nebbe 1996-11-06 0:00 ` To overload or not to overload (was Eiffel and Java + Ada dispatching) Don Harrison 1996-11-06 0:00 ` Robb Nebbe 1996-11-07 0:00 ` Norman H. Cohen 1996-11-07 0:00 ` Don Harrison 1996-11-07 0:00 ` Jon S Anthony 1996-11-07 0:00 ` Juergen Schlegelmilch 1996-11-08 0:00 ` Don Harrison 1996-11-08 0:00 ` Don Harrison 1996-11-14 0:00 ` Jon S Anthony 1996-11-14 0:00 ` Jon S Anthony 1996-11-07 0:00 ` Jon S Anthony 1996-11-11 0:00 ` Don Harrison 1996-11-08 0:00 ` bill.williams 1996-11-11 0:00 ` Don Harrison 1996-11-08 0:00 ` Eiffel and Java + Ada dispatching Robert I. Eachus 1996-11-06 0:00 ` Robert I. Eachus 1996-11-08 0:00 ` Don Harrison 1996-11-08 0:00 ` Jon S Anthony 1996-11-08 0:00 ` Robert A Duff 1996-11-12 0:00 ` Don Harrison 1996-11-12 0:00 ` Robert A Duff 1996-11-13 0:00 ` Don Harrison 1996-11-13 0:00 ` Jon S Anthony 1996-11-15 0:00 ` Don Harrison 1996-11-19 0:00 ` Jon S Anthony 1996-11-20 0:00 ` Don Harrison 1996-11-13 0:00 ` Robert A Duff 1996-11-14 0:00 ` Don Harrison 1996-11-12 0:00 ` Joachim Durchholz 1996-11-15 0:00 ` Richard Riehle 1996-11-16 0:00 ` Interfacing contracts (Was: Eiffel and Java + Ada dispatching) Geert Bosch 1996-11-17 0:00 ` Robert A Duff 1996-11-14 0:00 ` Eiffel and Java + Ada dispatching Robert I. Eachus 1996-11-14 0:00 ` Robert A Duff 1996-11-15 0:00 ` Don Harrison 1996-11-15 0:00 ` Robert I. Eachus 1996-11-19 0:00 ` Don Harrison 1996-11-18 0:00 ` Vincent Celier 1996-11-22 0:00 ` Don Harrison 1996-11-19 0:00 ` Jon S Anthony 1996-11-15 0:00 ` portmanteau (was Re: Eiffel and Java + Ada dispatching) Robert I. Eachus 1996-11-07 0:00 ` Eiffel and Java + Ada dispatching Robb Nebbe 1996-11-07 0:00 ` Jon S Anthony 1996-11-12 0:00 ` Jon S Anthony 1996-10-31 0:00 ` Joachim Durchholz 1996-11-01 0:00 ` Eiffel and Java Matthias Ernst 1996-11-01 0:00 ` William Clodius 1996-11-01 0:00 ` Benedict A. Gomes 1996-11-02 0:00 ` Eiffel and Java + Ada dispatching Jon S Anthony 1996-11-02 0:00 ` Jon S Anthony 1996-11-04 0:00 ` Eiffel and Java Robert I. Eachus 1996-10-30 0:00 ` Jon S Anthony 1996-11-01 0:00 ` Don Harrison 1996-11-01 0:00 ` Jon S Anthony 1996-11-07 0:00 ` Marcos F. F. de Macedo 1996-11-11 0:00 ` Ian Joyner 1996-11-12 0:00 ` Don Harrison 1996-11-13 0:00 ` Norman H. Cohen 1996-11-15 0:00 ` Don Harrison 1996-11-14 0:00 ` Jon S Anthony 1996-11-15 0:00 ` Don Harrison 1996-11-19 0:00 ` Jon S Anthony 1996-11-21 0:00 ` Don Harrison 1996-11-12 0:00 ` Jon S Anthony 1996-10-31 0:00 ` Joachim Durchholz 1996-11-01 0:00 ` Jon S Anthony 1996-11-02 0:00 ` Jon S Anthony 1996-11-03 0:00 ` Eiffel and Java + Ada dispatching Joachim Durchholz 1996-11-04 0:00 ` Eiffel and Java Richard A. O'Keefe -- strict thread matches above, loose matches on Subject: below -- 1996-10-28 0:00 cosc19z5@bayou.uh.edu [not found] ` <01bbc7f6$b1c0b7a0$LocalHost@gaijin> 1996-11-01 0:00 ` Ranjan Bagchi 1996-11-01 0:00 ` Alan Lovejoy 1996-11-01 0:00 ` Chris 1996-11-02 0:00 Ell 1996-11-02 0:00 ` traymond
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox