* Suggestion for Ada 200x - Interface inheritance @ 2003-05-23 23:05 Steve 2003-05-24 1:02 ` Robert A Duff ` (2 more replies) 0 siblings, 3 replies; 73+ messages in thread From: Steve @ 2003-05-23 23:05 UTC (permalink / raw) Java and C# use the concept of interface inheritance. What do you think of adding this feature to Ada? A tagged type containing only abstract methods (functions and procedures) would be considered to be an interface. Any tagged type may be dervied from at most one tagged type containing data elements and any number of interfaces. That is, you may define an interface: type interface_example is abstract tagged null record; function in_order( obj : interface_example ) return boolean; procedure swap( obj1, obj2 : in out interface_example ); type data_value is tagged record field1 : Natural; field2 : Natural; end record; type sorted_data is new data_value, interface_example with record is_valid : Boolean; end record; The objective is to add interfaces to existing objects such that they may be used by common routines, in the same way as Java. In fact this might make it easier to interface with Java. Steve (The Duck) ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-23 23:05 Suggestion for Ada 200x - Interface inheritance Steve @ 2003-05-24 1:02 ` Robert A Duff 2003-05-29 16:47 ` Brian Gaffney 2003-06-01 10:29 ` Craig Carey 2003-05-24 12:35 ` Wojtek Narczynski 2003-05-28 13:57 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Mário Amado Alves 2 siblings, 2 replies; 73+ messages in thread From: Robert A Duff @ 2003-05-24 1:02 UTC (permalink / raw) "Steve" <nospam_steved94@attbi.com> writes: > Java and C# use the concept of interface inheritance. What do you think of > adding this feature to Ada? I think it's a good idea. There is an AI on this, and I think the ARG is considering it one of the most urgent ones. Look up the AI, and see what you think. - Bob ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-24 1:02 ` Robert A Duff @ 2003-05-29 16:47 ` Brian Gaffney 2003-06-01 10:29 ` Craig Carey 1 sibling, 0 replies; 73+ messages in thread From: Brian Gaffney @ 2003-05-29 16:47 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcc3cj5i2cd.fsf@shell01.TheWorld.com>... > "Steve" <nospam_steved94@attbi.com> writes: > > > Java and C# use the concept of interface inheritance. What do you think of > > adding this feature to Ada? > > I think it's a good idea. There is an AI on this, and I think the ARG > is considering it one of the most urgent ones. Look up the AI, and see > what you think. > > - Bob (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00251.TXT?rev=1.12) I looked briefly at this AI (though I haven't read it in detail -- so I might have missed something), and there's one thing about it that I don't understand: If Ada'0Y is to add the concept of Interfaces, why would it be added as an Interface _type_? I can understand Java and C# using a Class-based approach, but since Ada splits up the concepts of a 'Class' wouldn't it be more the Ada-Way to use a concept related to packages? For example an "abstract package" which must have a body provided at the 'instantiation' site. I don't think this example would work, but something like: generic type Data is private; abstract package This_Interface is ... or abstract package This_Interface (type Data is private) is ... along with ... type Mine is ... package My_Interface is new This_Interface(Mine); package body My_Interface is ... ... I don't like this since My_Interface would be a different scope than that containing Data, but perhaps a way could be devised to annotate the type definition: type Mine is ... with This_Interface(Mine) ... or type Mine is ... for Data'interface use This_Interface(Mine), That_Interface(Mine), ...;" The bodies for subroutines, etc. defined in the Interfaces would then be required to follow (within the freezing rules?). This would give the advantage of allowing it for all types, not just tagged types. --Brian ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-24 1:02 ` Robert A Duff 2003-05-29 16:47 ` Brian Gaffney @ 2003-06-01 10:29 ` Craig Carey 1 sibling, 0 replies; 73+ messages in thread From: Craig Carey @ 2003-06-01 10:29 UTC (permalink / raw) On 23 May 2003 21:02:26 -0400, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: >"Steve" <nospam_steved94@attbi.com> writes: > >> Java and C# use the concept of interface inheritance. What do you think of >> adding this feature to Ada? > >I think it's a good idea. There is an AI on this, and I think the ARG >is considering it one of the most urgent ones. Look up the AI, and see >what you think. > http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00251.TXT The AI contains this comment: : **************************************************************** : : From: Randy Brukardt : Sent: Monday, December 04, 2000 10:31 PM ... : I note that the proposal never seems to state that abstract interface : types must not define any components. Certainly, the implementation : model and the entire discussion seem to assume that is the case. (An : "normal" abstract type can have components defined, they'll be part of : any extension; but I don't think we want that here.) : : **************************************************************** There seems to be inherent safety in avoiding O.O. and using subrecords. So... Mulitple Inheritance is doing something like making the parent record be subrecords of the new derived type. If the aim is flatten out subrecords so that fields names can conflict and fields can be accidentally not correctly set to a value, then the flattening could be made explicit with a way to rename Ada types. Here is an example showing variable X holding 4 integers. Due to the renaming of types, the 1st Integer is identified with the name X.A instead of: X.R1.A A sample extension of Ada: ------------------------------------------------------------------------ type T1 is tagged record A, B : Integer; end record; type T2 is tagged record B, C : Integer; end record; type Mixin is tagged record R1 : <> renames T1; -- Flatten T1's fields into Mixin record R2 : T2; end record; type Mixin renames Mixin.T2; -- Flatten T2's fields into Mixin record X : Mixin := Mixin'(A => 1, R1.B => 2, R2.B => 3, C => 4); ------------------------------------------------------------------------ I regard the idea of X'Class as a way to make it easy to unintentionally leave fields not-assigned-to. It would be harder to make that mistake when there are subrecords. The "MI" gain of shifting fields of a subrecord into the surrounding containing record must be quite slight if renaming has made it look like that has occurred when it actually hadn't. Craig Carey http://www.ijs.co.nz/ada_95.htm ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-23 23:05 Suggestion for Ada 200x - Interface inheritance Steve 2003-05-24 1:02 ` Robert A Duff @ 2003-05-24 12:35 ` Wojtek Narczynski 2003-05-24 17:53 ` Georg Bauhaus ` (3 more replies) 2003-05-28 13:57 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Mário Amado Alves 2 siblings, 4 replies; 73+ messages in thread From: Wojtek Narczynski @ 2003-05-24 12:35 UTC (permalink / raw) "Steve" <nospam_steved94@attbi.com> wrote in message news:<0Pxza.699607$OV.652508@rwcrnsc54>... > Java and C# use the concept of interface inheritance. What do you think of > adding this feature to Ada? > > A tagged type containing only abstract methods (functions and procedures) > would be considered to be an interface. Any tagged type may be dervied from > at most one tagged type containing data elements and any number of > interfaces. > > That is, you may define an interface: > > type interface_example is abstract tagged null record; > > function in_order( obj : interface_example ) return boolean; > > procedure swap( obj1, obj2 : in out interface_example ); > > type data_value is tagged > record > field1 : Natural; > field2 : Natural; > end record; > > type sorted_data is new data_value, interface_example with > record > is_valid : Boolean; > end record; > > The objective is to add interfaces to existing objects such that they may be > used by common routines, in the same way as Java. In fact this might make > it easier to interface with Java. > > Steve > (The Duck) I find your syntax cleaner than the AI proposal: http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00251.TXT?rev=1.12 This AI has a funny title: "Abstract Interfaces to provide Multiple Inheritance". Two misconceptions: 1. Interfaces cannot be concrete, 2. Interfaces do not provide multiple inheritance. They are just a different solution to to the problem. The AI proposes a new keyword 'interface' which, seems to have no purpose in existence of 'abstract tagged null record'. The new keyword approach also makes it impossible to reuse existing code that declares abstract tagged null records in place of interfaces. Or maybe could the new keyword 'interface' be used interchangably with the (lenthy) 'abstract tagged null record' clause? There is also this weirdness of 'abstract interface' at the begining, but I think the word 'abstract' has been dropped in later stages. The 'type T3 is new T1 and T2 and T3 with null record;' looks is weird as well. A simple comma like in your example is more readable. But I'll welcome whatever comes out, because the inability to create heterogenous collections just plain sucks. By the way, is there an AI for the second thing Ada could learn from Java, that is 'throws' clause? Regards, Wojtek ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-24 12:35 ` Wojtek Narczynski @ 2003-05-24 17:53 ` Georg Bauhaus 2003-05-25 13:11 ` Wojtek Narczynski 2003-05-24 22:07 ` Robert A Duff ` (2 subsequent siblings) 3 siblings, 1 reply; 73+ messages in thread From: Georg Bauhaus @ 2003-05-24 17:53 UTC (permalink / raw) Wojtek Narczynski <wojtek@power.com.pl> wrote: : : This AI has a funny title: "Abstract Interfaces to provide Multiple : Inheritance". Two misconceptions: 1. Interfaces cannot be concrete, Well, Java interfaces cannot in a sense be concrete, but there is more to the term "interface", which is a venerable, general purpose term dating from before the days of Java speak. Ada is a general purpose programming language... Georg ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-24 17:53 ` Georg Bauhaus @ 2003-05-25 13:11 ` Wojtek Narczynski 0 siblings, 0 replies; 73+ messages in thread From: Wojtek Narczynski @ 2003-05-25 13:11 UTC (permalink / raw) Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote in message news:<baobi7$pro$1@a1-hrz.uni-duisburg.de>... > Wojtek Narczynski <wojtek@power.com.pl> wrote: > : > : This AI has a funny title: "Abstract Interfaces to provide Multiple > : Inheritance". Two misconceptions: 1. Interfaces cannot be concrete, > > Well, Java interfaces cannot in a sense be concrete, but there > is more to the term "interface", which is a venerable, general purpose > term dating from before the days of Java speak. Ada is a general purpose > programming language... I get your point, but still I pefer talking about "interfaces" instead of "abstract interfaces", unless one defines what a "concrete interface" is, on the Ada ground. Objective-C has 'protocols' by the way, they are said to be ancestors of java interfaces. Regards, Wojtek ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-24 12:35 ` Wojtek Narczynski 2003-05-24 17:53 ` Georg Bauhaus @ 2003-05-24 22:07 ` Robert A Duff 2003-05-25 14:12 ` Wojtek Narczynski 2003-05-25 1:33 ` Steve 2003-05-26 7:49 ` Jean-Pierre Rosen 3 siblings, 1 reply; 73+ messages in thread From: Robert A Duff @ 2003-05-24 22:07 UTC (permalink / raw) wojtek@power.com.pl (Wojtek Narczynski) writes: > This AI has a funny title: "Abstract Interfaces to provide Multiple > Inheritance". Two misconceptions: 1. Interfaces cannot be concrete, 2. > Interfaces do not provide multiple inheritance. They are just a > different solution to to the problem. More than one interface can be inherited. That sounds like "multiple inheritance" to me. Java interface inheritance is just like C++ muliple inheritance, with the restriction that you can't inherit record components and procedure bodies. > But I'll welcome whatever comes out, because the inability to create > heterogenous collections just plain sucks. What do you mean by that? You can pass class-wide types to generic collection packages, and that's heterogeneous. I guess you mean you can't do what interface'Class allows... > By the way, is there an AI for the second thing Ada could learn from > Java, that is 'throws' clause? I think there's one about pre- and post-conditions, which is somewhat related. By the way, the ARG is not listening to your comments posted *here*. - Bob ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-24 22:07 ` Robert A Duff @ 2003-05-25 14:12 ` Wojtek Narczynski 2003-05-25 17:53 ` Jeffrey Carter 0 siblings, 1 reply; 73+ messages in thread From: Wojtek Narczynski @ 2003-05-25 14:12 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccznlcm226.fsf@shell01.TheWorld.com>... > More than one interface can be inherited. That sounds like "multiple > inheritance" to me. Java interface inheritance is just like C++ muliple > inheritance, with the restriction that you can't inherit record > components and procedure bodies. Usually you implement the interface. This likely comes from the Objective-C ground, where you have 'protocols' (different name, same role, said to be inspiration for Java interfaces). It's pretty natural that you implement a protocol, not inherit a protocol. In the same sense an interface/protocol can implement another interface/protocol. The question boils down to wether an interface is an ancestor of the type which implements (/inherits?) it. I think it is not, and thus prefer to talk about implementing the interface not inheriting it. For examle the USB interface is not an ancestor of my PC. > > But I'll welcome whatever comes out, because the inability to create > > heterogenous collections just plain sucks. > > What do you mean by that? You can pass class-wide types to generic > collection packages, and that's heterogeneous. I guess you mean you > can't do what interface'Class allows... I meant the situation where I needed to store objects from two libraries I could not put a common ancestor above. But I admit it is not the usual case. > > By the way, is there an AI for the second thing Ada could learn from > > Java, that is 'throws' clause? > > I think there's one about pre- and post-conditions, which is somewhat > related. Yeah. Pre- and post-conditions are easier, I guess, because they can't break current code, while the introduction of 'throws' ('raises'?), without some trick, would. Regards, Wojtek ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-25 14:12 ` Wojtek Narczynski @ 2003-05-25 17:53 ` Jeffrey Carter 2003-05-25 18:47 ` Wesley Groleau 0 siblings, 1 reply; 73+ messages in thread From: Jeffrey Carter @ 2003-05-25 17:53 UTC (permalink / raw) Wojtek Narczynski wrote: > > Yeah. Pre- and post-conditions are easier, I guess, because they can't > break current code, while the introduction of 'throws' ('raises'?), > without some trick, would. I would think we'd overload "raise" if this were introduced. Something like procedure Approach_Woman (Num_Beers_Drunk : in Natural) raise Your_Fly_Is_Open; perhaps? :) -- Jeff Carter "Now go away or I shall taunt you a second time." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-25 17:53 ` Jeffrey Carter @ 2003-05-25 18:47 ` Wesley Groleau 2003-05-25 19:42 ` Hyman Rosen 2003-05-26 7:51 ` Wojtek Narczynski 0 siblings, 2 replies; 73+ messages in thread From: Wesley Groleau @ 2003-05-25 18:47 UTC (permalink / raw) >> Yeah. Pre- and post-conditions are easier, I guess, because they can't >> break current code, while the introduction of 'throws' ('raises'?), >> without some trick, would. Indeed. I was asked to fix an out of bounds exception in Java once. Chased an empty string down through several layers of the call stack till I found that the class that was supposed to get the string out of a database caught file not found by creating an empty database, and handled no such key in the database by returning an empty string. For reasons which would take up unnecessary bandwidth, the right thing to do was throw an exception instead of pretending everything is OK for a later crash. But that meant adding a throws clause to each of hundreds of files. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-25 18:47 ` Wesley Groleau @ 2003-05-25 19:42 ` Hyman Rosen 2003-05-26 7:53 ` Wojtek Narczynski 2003-05-28 22:13 ` Robert A Duff 2003-05-26 7:51 ` Wojtek Narczynski 1 sibling, 2 replies; 73+ messages in thread From: Hyman Rosen @ 2003-05-25 19:42 UTC (permalink / raw) Wesley Groleau wrote: > But that meant adding a throws clause to each of hundreds of files. 'Throws' clauses are a really bad idea, the more so because it seems so right on first appraisal. C++ got lucky that because of legacy code requirements, no clause at all means that any exception may be thrown, and so once the idea was known to be bad, no one had to use it. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-25 19:42 ` Hyman Rosen @ 2003-05-26 7:53 ` Wojtek Narczynski 2003-05-26 15:50 ` Hyman Rosen 2003-05-28 22:13 ` Robert A Duff 1 sibling, 1 reply; 73+ messages in thread From: Wojtek Narczynski @ 2003-05-26 7:53 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<719Aa.14547$fT5.3595@nwrdny01.gnilink.net>... > Wesley Groleau wrote: > > But that meant adding a throws clause to each of hundreds of files. > > 'Throws' clauses are a really bad idea, the more so because it seems > so right on first appraisal. Why? Because it is a lot of typing? Regards, Wojtek ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-26 7:53 ` Wojtek Narczynski @ 2003-05-26 15:50 ` Hyman Rosen 2003-05-27 18:41 ` Wojtek Narczynski 0 siblings, 1 reply; 73+ messages in thread From: Hyman Rosen @ 2003-05-26 15:50 UTC (permalink / raw) Wojtek Narczynski wrote: > Why? Because it is a lot of typing? Because, as Wes demonstrated with a real life example, 'throws' clauses force the entanglement of classes that couldn't care less about the exceptions which are passing through them. Not the least of problems this causes is the implied coupling of classes that are in fact completely disjoint. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-26 15:50 ` Hyman Rosen @ 2003-05-27 18:41 ` Wojtek Narczynski 2003-05-27 18:55 ` Wesley Groleau 2003-05-27 19:13 ` Hyman Rosen 0 siblings, 2 replies; 73+ messages in thread From: Wojtek Narczynski @ 2003-05-27 18:41 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<PIqAa.18136$fT5.13411@nwrdny01.gnilink.net>... > Wojtek Narczynski wrote: > > Why? Because it is a lot of typing? > > Because, as Wes demonstrated with a real life example, > 'throws' clauses force the entanglement of classes that > couldn't care less about the exceptions which are passing > through them. Not the least of problems this causes is the > implied coupling of classes that are in fact completely > disjoint. But the situation where you cannot rely on the compiler to check wether you did not forget to put an exception handler in isn't good either. Maybe there is some middle ground, like declaring on package level which exceptions should be allowed to go through, and package level exception handlers? Regards, Wojtek ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-27 18:41 ` Wojtek Narczynski @ 2003-05-27 18:55 ` Wesley Groleau 2003-05-27 19:13 ` Hyman Rosen 1 sibling, 0 replies; 73+ messages in thread From: Wesley Groleau @ 2003-05-27 18:55 UTC (permalink / raw) > But the situation where you cannot rely on the compiler to check > wether you did not forget to put an exception handler in isn't good > either. Well, there are tools for analyzing for that. One of them is called "peer review" But some are less creative and MUCH faster. Too much dependence on "when others =>" contributes to a problem, though. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-27 18:41 ` Wojtek Narczynski 2003-05-27 18:55 ` Wesley Groleau @ 2003-05-27 19:13 ` Hyman Rosen 2003-05-28 13:07 ` Wojtek Narczynski 1 sibling, 1 reply; 73+ messages in thread From: Hyman Rosen @ 2003-05-27 19:13 UTC (permalink / raw) Wojtek Narczynski wrote: > But the situation where you cannot rely on the compiler to check > wether you did not forget to put an exception handler in isn't good > either. Yes it is. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-27 19:13 ` Hyman Rosen @ 2003-05-28 13:07 ` Wojtek Narczynski 2003-05-28 13:28 ` Jean-Pierre Rosen 2003-05-29 0:58 ` Hyman Rosen 0 siblings, 2 replies; 73+ messages in thread From: Wojtek Narczynski @ 2003-05-28 13:07 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<1054062833.558791@master.nyc.kbcfp.com>... > Wojtek Narczynski wrote: > > But the situation where you cannot rely on the compiler to check > > wether you did not forget to put an exception handler in isn't good > > either. > > Yes it is. So it's good to have the compiler check types and ranges, but it's not good to check exception propagation patterns. All clear, thank you. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-28 13:07 ` Wojtek Narczynski @ 2003-05-28 13:28 ` Jean-Pierre Rosen 2003-05-29 0:58 ` Hyman Rosen 1 sibling, 0 replies; 73+ messages in thread From: Jean-Pierre Rosen @ 2003-05-28 13:28 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 981 bytes --] "Wojtek Narczynski" <wojtek@power.com.pl> a �crit dans le message de news:5ad0dd8a.0305280507.57bd5a16@posting.google.com... > Hyman Rosen <hyrosen@mail.com> wrote in message news:<1054062833.558791@master.nyc.kbcfp.com>... > > Wojtek Narczynski wrote: > > > But the situation where you cannot rely on the compiler to check > > > wether you did not forget to put an exception handler in isn't good > > > either. > > > > Yes it is. > > So it's good to have the compiler check types and ranges, but it's not > good to check exception propagation patterns. All clear, thank you. Exceptions are for unexpected events. As the saying goes: "Once you've taken care of the unexpected, consider the unexpected unexpected". The nice things with exceptions as they are is that they allow you to deal with the unexpected unexpected. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-28 13:07 ` Wojtek Narczynski 2003-05-28 13:28 ` Jean-Pierre Rosen @ 2003-05-29 0:58 ` Hyman Rosen 1 sibling, 0 replies; 73+ messages in thread From: Hyman Rosen @ 2003-05-29 0:58 UTC (permalink / raw) Wojtek Narczynski wrote: > So it's good to have the compiler check types and ranges, but it's not > good to check exception propagation patterns. All clear, thank you. You're welcome. The difference, of course, is that it's an error to mix types incorrectly, or to wander out of range, but it's not an error to ignore an exception. That's exactly what exceptions are for, to be ignored by code that wants to ignore them, until they reach an interested handler. Explicit expressions of disinterest are wrong, because the universe of things in which to be disintersted in is ever expanding. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-25 19:42 ` Hyman Rosen 2003-05-26 7:53 ` Wojtek Narczynski @ 2003-05-28 22:13 ` Robert A Duff 2003-05-28 23:50 ` Hyman Rosen ` (2 more replies) 1 sibling, 3 replies; 73+ messages in thread From: Robert A Duff @ 2003-05-28 22:13 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > Wesley Groleau wrote: > > But that meant adding a throws clause to each of hundreds of files. > > 'Throws' clauses are a really bad idea, the more so because it seems > so right on first appraisal. Throws clauses are a bad idea in Java, because they require scattering a whole lot of useless exception handlers all over the place. Or else a whole lot of useless throws clauses. But I don't think they're a fundamentally bad idea; I think it would be possible to design a language without those problems. One thing Java got right is that there are two kinds of exceptions: For one kind, you want to declare "this procedure can raise X", and force callers to either handle it or declare that they throw it. For the other kind, you don't want to declare anything. One thing Java got wrong is the some of the exceptions are in the wrong category. For example, all the streams operations can throw I/O exceptions, even though streams are not necessarily tied to I/O. If an open-file operation is designed to raise a file-not-found exception, then I think it's reasonable to require the caller to handle it (or reraise it). But a read-from-stream operation should not require any extra mumbo-jumbo at the call site; it might not even be reading from a file. I also think you should let the programmer decide which exceptions are in which category. For example, an out-of-memory exception (Storage_Error, in Ada) should, by default, not require any declarations, since pretty-much anything can raise it. But in an embedded system, you might want the compiler to prove that out-of-memory can't happen. I envision a compiler that calculates (at link time) a worst-case stack size for every procedure (including called procedures). The programmer could say, "on entry to this procedure, make sure there's enough stack space". If the procedure is recursive, or declares something like: X: String(1..N); where N is not known, the "worst case" would be "the size of the whole address space". But if you don't do those things, the "worst case" could be reasonable, and the compiler could prove at compile time (link time, really) that certain regions of code (perhaps the whole program) do not run out of stack space. Consider also something like a generic iterator: generic with procedure Action(X: Element); procedure Set_Iterate(S: Set); -- Calls Action once for each element of the Set. Presumably Set_Iterate can raise whatever exceptions are raised by the actual procedure passed to Action. But you don't want to say Set_Iterate raises "any exception". You want to say, "Set_Iterate raises whatever exceptions are raised by Action". That's not known at compile time of the generic, but it could be known at compile time of the instantiations. So for "throws clauses" to work well, we need some sort of pass-through concept -- "this throws what that throws". This would allow abstraction layers that simply pass exceptions through to avoid saying "throws anything" and the subsequent clutter in clients. Another point is that most exceptions are really preconditions. See Eiffel, and design-by-contract. You want to declare not only that this procedure raises Queue_Empty_Error, but also under what conditions that exception is raised (e.g. if Is_Empty is True), and that Queue_Empty_Error gets raised before modifying the queue. And if you have pre- and postconditions, I think you want to attach postconditions to exceptional situations. You want a way to express, "If this procedure returns normally, then such-and-such is true. If it raises File_Not_Found, then so-and-so is true. And if it raises Storage_Error, all bets are off (i.e., any data touched by this procedure might have been damaged, so don't touch it)." And finally, you want user-settable defaults. Like, "All procedures in this package, and all of its descendants, behave such-and-such a way in the presence of so-and-so exception." - Bob ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-28 22:13 ` Robert A Duff @ 2003-05-28 23:50 ` Hyman Rosen 2003-05-29 9:17 ` Dmitry A. Kazakov 2003-05-29 13:31 ` Wojtek Narczynski 2 siblings, 0 replies; 73+ messages in thread From: Hyman Rosen @ 2003-05-28 23:50 UTC (permalink / raw) Robert A Duff wrote: > I think it would be possible to design a > language without those problems. Maybe. I'll believe it when I see it, though. I think that there is a fundamental incoherency here - exceptions are designed to be a "long-distance" method of error handling; you throw where the error is noticed, and the closest interested handler gets invoked. This style means that the code in between explicitly does not want to know about the exception, because if it did, then it would have a handler. So forcing the code to declaim all the things in which it is not interested is counterproductive and useless. And as you point out, the problem is even more basic when it comes to generics. Which reminds me that I'll bet this will be another phonied up aspect of generics in Java. Odds are you won't be able to specify the generic parameter in a throws clause. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-28 22:13 ` Robert A Duff 2003-05-28 23:50 ` Hyman Rosen @ 2003-05-29 9:17 ` Dmitry A. Kazakov 2003-05-29 13:31 ` Wojtek Narczynski 2 siblings, 0 replies; 73+ messages in thread From: Dmitry A. Kazakov @ 2003-05-29 9:17 UTC (permalink / raw) Robert A Duff wrote: > Hyman Rosen <hyrosen@mail.com> writes: > >> Wesley Groleau wrote: >> > But that meant adding a throws clause to each of hundreds of files. >> >> 'Throws' clauses are a really bad idea, the more so because it seems >> so right on first appraisal. > > Throws clauses are a bad idea in Java, because they require scattering a > whole lot of useless exception handlers all over the place. Or else a > whole lot of useless throws clauses. But I don't think they're a > fundamentally bad idea; I think it would be possible to design a > language without those problems. > > One thing Java got right is that there are two kinds of exceptions: > For one kind, you want to declare "this procedure can raise X", > and force callers to either handle it or declare that they throw it. > For the other kind, you don't want to declare anything. I do not think it is a good idea. The set of exceptions is countable for any given program, I hope. (:-)) I would like to declare: f potentially raises what A, B, C may raise and also the exceptions W and V, but not the exceptions X, Y, Z. > One thing Java got wrong is the some of the exceptions are in the wrong > category. For example, all the streams operations can throw I/O > exceptions, even though streams are not necessarily tied to I/O. > If an open-file operation is designed to raise a file-not-found > exception, then I think it's reasonable to require the caller to handle > it (or reraise it). But a read-from-stream operation should not require > any extra mumbo-jumbo at the call site; it might not even be reading > from a file. > > I also think you should let the programmer decide which exceptions are > in which category. For example, an out-of-memory exception > (Storage_Error, in Ada) should, by default, not require any > declarations, since pretty-much anything can raise it. > But in an embedded system, you might want the compiler to prove that > out-of-memory can't happen. I envision a compiler that calculates (at > link time) a worst-case stack size for every procedure (including called > procedures). The programmer could say, "on entry to this procedure, > make sure there's enough stack space". If the procedure is recursive, > or declares something like: > > X: String(1..N); > > where N is not known, the "worst case" would be "the size of the whole > address space". But if you don't do those things, the "worst case" > could be reasonable, and the compiler could prove at compile time (link > time, really) that certain regions of code (perhaps the whole program) > do not run out of stack space. > > Consider also something like a generic iterator: > > generic > with procedure Action(X: Element); > procedure Set_Iterate(S: Set); > -- Calls Action once for each element of the Set. > > Presumably Set_Iterate can raise whatever exceptions are raised by the > actual procedure passed to Action. But you don't want to say > Set_Iterate raises "any exception". You want to say, "Set_Iterate > raises whatever exceptions are raised by Action". That's not known at > compile time of the generic, but it could be known at compile time of > the instantiations. > > So for "throws clauses" to work well, we need some sort of pass-through > concept -- "this throws what that throws". This would allow abstraction > layers that simply pass exceptions through to avoid saying "throws > anything" and the subsequent clutter in clients. This is a simple inheritance model. A derivant inherits the contract which includes "throws clauses". It may strengthen it by saying "I will not throw X". Then the implementation of derivant has to catch X. > Another point is that most exceptions are really preconditions. Of course. > See > Eiffel, and design-by-contract. You want to declare not only that this > procedure raises Queue_Empty_Error, but also under what conditions that > exception is raised (e.g. if Is_Empty is True), and that > Queue_Empty_Error gets raised before modifying the queue. > > And if you have pre- and postconditions, I think you want to attach > postconditions to exceptional situations. You want a way to express, > "If this procedure returns normally, then such-and-such is true. If it > raises File_Not_Found, then so-and-so is true. And if it raises > Storage_Error, all bets are off (i.e., any data touched by this > procedure might have been damaged, so don't touch it)." Semantics of exceptions as a part of the contract, I like it. Of course, "throw clauses" has to be inherited with pre- and postconditions upon exceptions. Then a derivant may tune those. If it promises not to raise an exception then it is same as to say that the precondition of the exception is False. > And finally, you want user-settable defaults. Like, "All procedures in > this package, and all of its descendants, behave such-and-such a way in > the presence of so-and-so exception." -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-28 22:13 ` Robert A Duff 2003-05-28 23:50 ` Hyman Rosen 2003-05-29 9:17 ` Dmitry A. Kazakov @ 2003-05-29 13:31 ` Wojtek Narczynski 2 siblings, 0 replies; 73+ messages in thread From: Wojtek Narczynski @ 2003-05-29 13:31 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccd6i2yb1s.fsf@shell01.TheWorld.com>... > I also think you should let the programmer decide which exceptions are > in which category. For example, an out-of-memory exception > (Storage_Error, in Ada) should, by default, not require any > declarations, since pretty-much anything can raise it. Just to clarify. In Java 'out of memory' is an Error, not Exception. You never need to declare it in throws clause, and you very rarely throw it by yourself, only when you are are doing malloc() by yourself. > Another point is that most exceptions are really preconditions. Yes! For example the Java IllegalArgument exception, you don't need to declare it, but practically most methods should throw it. Preconditions would do the job much better. > And finally, you want user-settable defaults. Like, "All procedures in > this package, and all of its descendants, behave such-and-such a way in > the presence of so-and-so exception." Yeah, I would want this. Regards, Wojtek ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-25 18:47 ` Wesley Groleau 2003-05-25 19:42 ` Hyman Rosen @ 2003-05-26 7:51 ` Wojtek Narczynski 1 sibling, 0 replies; 73+ messages in thread From: Wojtek Narczynski @ 2003-05-26 7:51 UTC (permalink / raw) Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<iYWdna3UTaIzkkyjXTWcoA@gbronline.com>... > But that meant adding a throws clause to each of hundreds of > files. People tend to heavily abuse 'throw new XxxxException' instead of 'throw new Error'. The difference is that Excetions are supposed to be handled gracefully while Errors should cause the JVM to die. So when you know that you cannot go on, you just throw an Error. In library code you'll often throw exceptions, but in application code you'll often catch an exception just to throw an error. Regards, Wojtek ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-24 12:35 ` Wojtek Narczynski 2003-05-24 17:53 ` Georg Bauhaus 2003-05-24 22:07 ` Robert A Duff @ 2003-05-25 1:33 ` Steve 2003-05-25 10:37 ` Simon Wright 2003-05-26 7:54 ` Jean-Pierre Rosen 2003-05-26 7:49 ` Jean-Pierre Rosen 3 siblings, 2 replies; 73+ messages in thread From: Steve @ 2003-05-25 1:33 UTC (permalink / raw) Thanks. I looked at AI-251. It looks like it is covered.. Here's another one: Ada currently permits giving the names of operands to functions and procedures from the caller: Example: function Add( left, right : Natural ) return Natural; May be called using: result := Add( left => 2, right => 3 ); Use of the names is optional, but if they are present they must match. What do you think of the idea of also optionally giving the mode of the parameter, which if present must match the function or procedure declaration. That is, extending the above example: result := Add( in left => 2, in right => 3 ); Why? Readability. When reading code it is sometimes unclear from the caller whether or not a procedure modifies its parameters. Adding this feature would permit specifying this explicitly. I realize I haven't chosen the best example since functions only permit "in" parameters, but you probably get the idea. It really enhances readability with certain procedure calls such as: Copy( out buf_1 => a, in buf_2 => b ); Of course bettern naming conventions would help readability in this example. I could even imagine a pragma that requiring such qualification to enforce coding conventions. Steve (The Duck) "Wojtek Narczynski" <wojtek@power.com.pl> wrote in message news:5ad0dd8a.0305240435.337d9373@posting.google.com... > "Steve" <nospam_steved94@attbi.com> wrote in message news:<0Pxza.699607$OV.652508@rwcrnsc54>... [snip] > > I find your syntax cleaner than the AI proposal: > > http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00251.TXT?rev=1.12 > > This AI has a funny title: "Abstract Interfaces to provide Multiple > Inheritance". Two misconceptions: 1. Interfaces cannot be concrete, 2. > Interfaces do not provide multiple inheritance. They are just a > different solution to to the problem. [snip] > > Regards, > Wojtek ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-25 1:33 ` Steve @ 2003-05-25 10:37 ` Simon Wright 2003-05-26 7:54 ` Jean-Pierre Rosen 1 sibling, 0 replies; 73+ messages in thread From: Simon Wright @ 2003-05-25 10:37 UTC (permalink / raw) "Steve" <nospam_steved94@attbi.com> writes: > It really enhances readability with certain procedure calls such as: > > Copy( out buf_1 => a, in buf_2 => b ); > > Of course better naming conventions would help readability in this > example. Indeed. Copy (From => A, To => B); in this simple example. I find people don't always think of the subprograms they're providing from the point of view of the people who are going to use them. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-25 1:33 ` Steve 2003-05-25 10:37 ` Simon Wright @ 2003-05-26 7:54 ` Jean-Pierre Rosen 2003-05-26 10:07 ` Preben Randhol 2003-06-01 10:53 ` Craig Carey 1 sibling, 2 replies; 73+ messages in thread From: Jean-Pierre Rosen @ 2003-05-26 7:54 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 872 bytes --] "Steve" <nospam_steved94@attbi.com> a �crit dans le message de news:m3Vza.963555$3D1.566040@sccrnsc01... > What do you think of the idea of also optionally giving the mode of the > parameter, which if present must match the function or procedure > declaration. That is, extending the above example: > > result := Add( in left => 2, in right => 3 ); > Sigh... In the green language proposal, associations between formal and actual used ":=" for in parameters, "=:" for out parameters, and ":=:" for in out parameters. It was later dropped, I don't remember why, but presumably because it was felt that the gain was not worth the extra complexity. So this idea, although it has some merit, is not really new... -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-26 7:54 ` Jean-Pierre Rosen @ 2003-05-26 10:07 ` Preben Randhol 2003-05-26 16:32 ` Pascal Obry 2003-06-01 10:53 ` Craig Carey 1 sibling, 1 reply; 73+ messages in thread From: Preben Randhol @ 2003-05-26 10:07 UTC (permalink / raw) Jean-Pierre Rosen wrote: > Sigh... In the green language proposal, associations between formal > and actual used ":=" for in parameters, "=:" for out parameters, and > ":=:" for in out parameters. > > It was later dropped, I don't remember why, but presumably because it > was felt that the gain was not worth the extra complexity. I don't know why it was dropped, but I would say why I would drop it it would be that it has very low readability. := and =: are too similar and an error can easily be overlooked IMHO. At least I know *I* could easily do that mistake. -- Preben Randhol http://www.pvv.org/~randhol/ ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-26 10:07 ` Preben Randhol @ 2003-05-26 16:32 ` Pascal Obry 2003-05-26 16:59 ` Preben Randhol 0 siblings, 1 reply; 73+ messages in thread From: Pascal Obry @ 2003-05-26 16:32 UTC (permalink / raw) Preben Randhol <randhol+abuse@pvv.org> writes: > I don't know why it was dropped, but I would say why I would drop it it > would be that it has very low readability. := and =: are too similar and > an error can easily be overlooked IMHO. At least I know *I* could easily > do that mistake. But that's not a big problem since the compiler would detect such errors. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-26 16:32 ` Pascal Obry @ 2003-05-26 16:59 ` Preben Randhol 0 siblings, 0 replies; 73+ messages in thread From: Preben Randhol @ 2003-05-26 16:59 UTC (permalink / raw) Pascal Obry wrote: > > But that's not a big problem since the compiler would detect such errors. Sure, but it would afwully annoying to all the time get the : at the right side of the =. But my main point it doesn't give much information to the *eye* that reads the code. -- Preben Randhol http://www.pvv.org/~randhol/ ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-26 7:54 ` Jean-Pierre Rosen 2003-05-26 10:07 ` Preben Randhol @ 2003-06-01 10:53 ` Craig Carey 2003-06-01 12:17 ` Preben Randhol 1 sibling, 1 reply; 73+ messages in thread From: Craig Carey @ 2003-06-01 10:53 UTC (permalink / raw) On Mon, 26 May 2003 09:54:07 +0200, "Jean-Pierre Rosen" <rosen@adalog.fr> wrote: >"Steve" <nospam_steved94@attbi.com> a �crit dans le message de news:m3Vza.963555$3D1.566040@sccrnsc01... >> What do you think of the idea of also optionally giving the mode of the >> parameter, which if present must match the function or procedure >> declaration. That is, extending the above example: >> >> result := Add( in left => 2, in right => 3 ); >> >Sigh... In the green language proposal, associations between formal and actual used ":=" > for in parameters, >"=:" for out parameters, and ":=:" for in out parameters. > >It was later dropped, How interesting. Instead of "=:", ":=:", ":=", these may be used: "/" [constant 'in' mode parameter for the procedure or generic], "|" [in out], and "\" [out]. Two examples of calling a procedure: Text_IO.Get_Line (/File, \Item, \Last); Text_IO.Get_Line (/File, \Item => Item, \Last => Last); Craig Carey http://www.ijs.co.nz/ada_95.htm ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-06-01 10:53 ` Craig Carey @ 2003-06-01 12:17 ` Preben Randhol 0 siblings, 0 replies; 73+ messages in thread From: Preben Randhol @ 2003-06-01 12:17 UTC (permalink / raw) Craig Carey wrote: > "/" [constant 'in' mode parameter for the procedure or generic], > "|" [in out], and > "\" [out]. > > Two examples of calling a procedure: > > Text_IO.Get_Line (/File, \Item, \Last); > > Text_IO.Get_Line (/File, \Item => Item, \Last => Last); IMHO awful. We are saying Ada is more readable because it uses less whitespaces so why should we now start adding more whitespaces which makes the code less readable? -- Preben Randhol http://www.pvv.org/~randhol/ ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-24 12:35 ` Wojtek Narczynski ` (2 preceding siblings ...) 2003-05-25 1:33 ` Steve @ 2003-05-26 7:49 ` Jean-Pierre Rosen 2003-06-02 9:01 ` Wojtek Narczynski 3 siblings, 1 reply; 73+ messages in thread From: Jean-Pierre Rosen @ 2003-05-26 7:49 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 767 bytes --] "Wojtek Narczynski" <wojtek@power.com.pl> a �crit dans le message de news:5ad0dd8a.0305240435.337d9373@posting.google.com... > "Steve" <nospam_steved94@attbi.com> wrote in message news:<0Pxza.699607$OV.652508@rwcrnsc54>... > But I'll welcome whatever comes out, because the inability to create > heterogenous collections just plain sucks. > "Inability" is an overstatement. Of course, you can create heterogenous collections in Ada, it just requires you to follow a certain design pattern. See my last year's Ada-Europe paper for how to do that (available at http://www.adalog.fr/publicat/ada-interfaces.pdf) -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: Suggestion for Ada 200x - Interface inheritance 2003-05-26 7:49 ` Jean-Pierre Rosen @ 2003-06-02 9:01 ` Wojtek Narczynski 0 siblings, 0 replies; 73+ messages in thread From: Wojtek Narczynski @ 2003-06-02 9:01 UTC (permalink / raw) "Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message news:<8khsab.h94.ln@skymaster>... > "Inability" is an overstatement. Yeah, I overstated it... > See my last year's Ada-Europe paper for how to do that > (available at http://www.adalog.fr/publicat/ada-interfaces.pdf) It seems to me that the idea that 'abstract tagged null record' is 'interface enough' already pops-up every now and then. It is a valid point that you can simulate interfaces with inner classes / record components. But you can also write object oriented code in raw C (see GNOME), it's rather the decision which constructs to make first class citizens of a given language. Your paper also shows that interfaces should not be hard to implement in compilers. Right? Thank you, Wojtek ^ permalink raw reply [flat|nested] 73+ messages in thread
* MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) 2003-05-23 23:05 Suggestion for Ada 200x - Interface inheritance Steve 2003-05-24 1:02 ` Robert A Duff 2003-05-24 12:35 ` Wojtek Narczynski @ 2003-05-28 13:57 ` Mário Amado Alves 2003-05-28 15:05 ` Preben Randhol ` (2 more replies) 2 siblings, 3 replies; 73+ messages in thread From: Mário Amado Alves @ 2003-05-28 13:57 UTC (permalink / raw) "Steve" <nospam_steved94@attbi.com> wrote in message news:<0Pxza.699607$OV.652508@rwcrnsc54> > . . . > type sorted_data is new data_value, interface_example with > record > is_valid : Boolean; > end record; > . . . This is simply multiple inheritance (MI) in the Ada class system. Calling it "interface" just confuses the issue. (I can do interfaces with generics, formal packages, access-to-subprogram types, etc.) Everybody wants class MI. The reasons it was left out of Ada 95 and 83, the cons, are weaker than the pros. So every Adaist whishes to see it in Ada 200X. Along with the nice syntaxes. Personally I prefer "and" to ",". And, yes, ";" to "abstract tagged with null record". (Or is it "tagged abstract null record"? Or "abstract tagged null record"? ;-) ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) 2003-05-28 13:57 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Mário Amado Alves @ 2003-05-28 15:05 ` Preben Randhol 2003-05-29 0:54 ` MI in Ada 200X Hyman Rosen 2003-05-29 9:17 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Dmitry A. Kazakov 2003-05-29 0:54 ` MI in Ada 200X Hyman Rosen 2003-05-29 2:13 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Robert I. Eachus 2 siblings, 2 replies; 73+ messages in thread From: Preben Randhol @ 2003-05-28 15:05 UTC (permalink / raw) M�rio Amado Alves wrote: > Everybody wants class MI. The reasons it was left out of Ada 95 and > 83, the cons, are weaker than the pros. So every Adaist whishes to see > it in Ada 200X. Convince me :-) Seriously what are the pros and cons of MI. -- Preben Randhol http://www.pvv.org/~randhol/ ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-28 15:05 ` Preben Randhol @ 2003-05-29 0:54 ` Hyman Rosen 2003-05-29 17:38 ` Stephen Leake 2003-05-30 7:20 ` Preben Randhol 2003-05-29 9:17 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Dmitry A. Kazakov 1 sibling, 2 replies; 73+ messages in thread From: Hyman Rosen @ 2003-05-29 0:54 UTC (permalink / raw) Preben Randhol wrote: > Seriously what are the pros and cons of MI. If SI is considered useful, I fail to see why MI would not be considered useful. Implementing MI has its difficulties, related to complicated memory layouts, casting, and so forth. You can get an idea for the complexities by looking up the C++ ABI that gcc implements. Here's a particular example which is ever annoying in Java. A common design pattern in Java is to have an interface, and then make a companion class which implements the interface and provides do-nothing implementations for all the methods. If you want a class which implements both interfaces and does nothing for most of the methods, you can't inherit from both companion classes. Instead, you must reimplement at least one set of the dunsel methods. C++ also has its stream classes, where istream and ostream inherit from an ios_base, and then iostream inherits from istream and ostream. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-29 0:54 ` MI in Ada 200X Hyman Rosen @ 2003-05-29 17:38 ` Stephen Leake 2003-05-30 7:20 ` Preben Randhol 1 sibling, 0 replies; 73+ messages in thread From: Stephen Leake @ 2003-05-29 17:38 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > Here's a particular example which is ever annoying in Java. A > common design pattern in Java is to have an interface, and then > make a companion class which implements the interface and provides > do-nothing implementations for all the methods. If you want a class > which implements both interfaces and does nothing for most of the > methods, you can't inherit from both companion classes. Instead, > you must reimplement at least one set of the dunsel methods. Interestingly, the Ada interface type proposal AI solves this particular problem, by allowing interface types to have explicitly null procedures: type T is interface; procedure Foo (Item : in T) is null; :). -- -- Stephe ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-29 0:54 ` MI in Ada 200X Hyman Rosen 2003-05-29 17:38 ` Stephen Leake @ 2003-05-30 7:20 ` Preben Randhol 1 sibling, 0 replies; 73+ messages in thread From: Preben Randhol @ 2003-05-30 7:20 UTC (permalink / raw) Hyman Rosen wrote: > Preben Randhol wrote: > > Seriously what are the pros and cons of MI. > > If SI is considered useful, I fail to see why MI would not be > considered useful. Implementing MI has its difficulties, related > to complicated memory layouts, casting, and so forth. You can get > an idea for the complexities by looking up the C++ ABI that gcc > implements. Well it depends on what you want to do and where you are. But I'm interested to see how the pros outweighs the cons. -- Preben Randhol http://www.pvv.org/~randhol/ ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) 2003-05-28 15:05 ` Preben Randhol 2003-05-29 0:54 ` MI in Ada 200X Hyman Rosen @ 2003-05-29 9:17 ` Dmitry A. Kazakov 2003-05-29 22:56 ` MI in Ada 200X Hyman Rosen ` (2 more replies) 1 sibling, 3 replies; 73+ messages in thread From: Dmitry A. Kazakov @ 2003-05-29 9:17 UTC (permalink / raw) Preben Randhol wrote: > Mário Amado Alves wrote: > >> Everybody wants class MI. The reasons it was left out of Ada 95 and >> 83, the cons, are weaker than the pros. So every Adaist whishes to see >> it in Ada 200X. > > Convince me :-) Seriously what are the pros and cons of MI. Hey, the burden of proof is on your side! (:-)). SI is an artificially restricted MI. Consider overloading allowed only in one argument. Silly? Then convince me that you really need it for two arguments. And, well, there are work-arounds A, B, C etc. Now consider a possibility that MI has a problem X. Then, obviously, either X is a problem of the concept of inheritance (1), or X is a problem of the language, implementation, our understanding etc (2). Thus either: (1) we should better dismiss SI as well. or (2) we should carefuly check the language to implement MI correctly. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-29 9:17 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Dmitry A. Kazakov @ 2003-05-29 22:56 ` Hyman Rosen 2003-05-30 7:39 ` Dmitry A. Kazakov 2003-05-30 15:11 ` Mark A. Biggar 2003-05-30 2:50 ` Wesley Groleau 2003-05-30 8:46 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Preben Randhol 2 siblings, 2 replies; 73+ messages in thread From: Hyman Rosen @ 2003-05-29 22:56 UTC (permalink / raw) Dmitry A. Kazakov wrote: > Now consider a possibility that MI has a problem X. Then, obviously, either > X is a problem of the concept of inheritance (1), or X is a problem of the > language, implementation, our understanding etc (2). MI has implementation difficulties that are distinct from SI, related to the layout in memory of the pieces of the full object. As I said, it is very instructive to check out the C++ ABI which gcc uses. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-29 22:56 ` MI in Ada 200X Hyman Rosen @ 2003-05-30 7:39 ` Dmitry A. Kazakov 2003-05-30 13:11 ` Hyman Rosen 2003-05-30 15:11 ` Mark A. Biggar 1 sibling, 1 reply; 73+ messages in thread From: Dmitry A. Kazakov @ 2003-05-30 7:39 UTC (permalink / raw) Hyman Rosen wrote: > Dmitry A. Kazakov wrote: >> Now consider a possibility that MI has a problem X. Then, obviously, >> either X is a problem of the concept of inheritance (1), or X is a >> problem of the language, implementation, our understanding etc (2). > > MI has implementation difficulties that are distinct from SI, > related to the layout in memory of the pieces of the full object. We already had a discussion about implementation vs. interface inheritance. BTW this thread started from abstract interface inheritance and then jumped to more general cases of MI. Which is a valid point. Any concept adopted by a language has to be extended to its natural limits, to the point where no further extension possible. How often people use multi-dimensional arrays? Once per year? Yet Ada has them. There is nothing worse in language design, than arbitrary constraints. The difficulties you are talking about is just one particular case caused by attempts to equalize specific and class-wide objects (embedded tags, by-reference semantics etc.) There is other way, I hope. > As I said, it is very instructive to check out the C++ ABI which > gcc uses. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 7:39 ` Dmitry A. Kazakov @ 2003-05-30 13:11 ` Hyman Rosen 2003-05-30 14:29 ` Robert A Duff 0 siblings, 1 reply; 73+ messages in thread From: Hyman Rosen @ 2003-05-30 13:11 UTC (permalink / raw) Dmitry A. Kazakov wrote: > There is other way, I hope. I feel certain that your way will never be adopted. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 13:11 ` Hyman Rosen @ 2003-05-30 14:29 ` Robert A Duff 2003-05-30 14:51 ` Hyman Rosen 0 siblings, 1 reply; 73+ messages in thread From: Robert A Duff @ 2003-05-30 14:29 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > Dmitry A. Kazakov wrote: > > There is other way, I hope. > > I feel certain that your way will never be adopted. Neither will saturating arithmetic, but it's still fun to talk about language design ideas. ;-) - Bob ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 14:29 ` Robert A Duff @ 2003-05-30 14:51 ` Hyman Rosen 0 siblings, 0 replies; 73+ messages in thread From: Hyman Rosen @ 2003-05-30 14:51 UTC (permalink / raw) Robert A Duff wrote: > Neither will saturating arithmetic, but it's still fun to talk about > language design ideas. ;-) Yep. It's just that keeping the virtualness with the pointer instead of with the object means that you immediately sacrifice representation compatibility with C++, which is just going to run the concept into a wall of opposition. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-29 22:56 ` MI in Ada 200X Hyman Rosen 2003-05-30 7:39 ` Dmitry A. Kazakov @ 2003-05-30 15:11 ` Mark A. Biggar 2003-05-30 15:51 ` Hyman Rosen 2003-05-30 22:38 ` John Griffiths 1 sibling, 2 replies; 73+ messages in thread From: Mark A. Biggar @ 2003-05-30 15:11 UTC (permalink / raw) Hyman Rosen wrote: > Dmitry A. Kazakov wrote: > >> Now consider a possibility that MI has a problem X. Then, obviously, >> either X is a problem of the concept of inheritance (1), or X is a >> problem of the language, implementation, our understanding etc (2). > > > MI has implementation difficulties that are distinct from SI, > related to the layout in memory of the pieces of the full object. > As I said, it is very instructive to check out the C++ ABI which > gcc uses. > MI also has the ambiguities with the diamond inheritance problem, which I have never seen a language solve in a non-clumsy way. Suppose we have the following example: type a is tagged ...; procedure op(x: a); type b is new a with ...; procedure op(x: b); type c is new a with ...; procedure op(x: C); type d is new a and b with ...; -- made up notation for Ada MI procedure op(x: d); Now for the ambiguities: 1) does d contain 1 or 2 copies of the fields of a? 2) if 2 how do you name them? 3) which version of op does d inherit? 4) the simple implementation (TAG is pointer to vtable, field offsets remain constant, etc.) becomes much more complicated. -- mark@biggar.org mark.a.biggar@attbi.com ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 15:11 ` Mark A. Biggar @ 2003-05-30 15:51 ` Hyman Rosen 2003-05-30 22:38 ` John Griffiths 1 sibling, 0 replies; 73+ messages in thread From: Hyman Rosen @ 2003-05-30 15:51 UTC (permalink / raw) Mark A. Biggar wrote: > 1) does d contain 1 or 2 copies of the fields of a? In C++ you choose, by specifying virtual inheritance or not. > 2) if 2 how do you name them? Do a view conversion to the appropriate base class. > 3) which version of op does d inherit? Neither. Attemping to call op on a d object would be a compile-time error. > 4) the simple implementation (TAG is pointer to vtable, field offsets > remain constant, etc.) becomes much more complicated. Yes, but this is a job for the implementors, which they need to do just once. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 15:11 ` Mark A. Biggar 2003-05-30 15:51 ` Hyman Rosen @ 2003-05-30 22:38 ` John Griffiths 1 sibling, 0 replies; 73+ messages in thread From: John Griffiths @ 2003-05-30 22:38 UTC (permalink / raw) <snip> "Mark A. Biggar" <mark@biggar.org> wrote in message news:9wKBa.1046187$F1.124536@sccrnsc04... </snip> <snip> MI also has the ambiguities with the diamond inheritance problem, which I have never seen a language solve in a non-clumsy way. </snip> Has any language allowed MI but forbidden mutual inheritance (the existence of a common inheritor between two classes - excluding a universal base class if language is strictly OOP)? What's the way Eiffel does it? ISTR it didn't care one way or another about common ancestry. Regards John ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-29 9:17 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Dmitry A. Kazakov 2003-05-29 22:56 ` MI in Ada 200X Hyman Rosen @ 2003-05-30 2:50 ` Wesley Groleau 2003-05-30 7:38 ` Dmitry A. Kazakov 2003-05-30 8:28 ` Mário Amado Alves 2003-05-30 8:46 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Preben Randhol 2 siblings, 2 replies; 73+ messages in thread From: Wesley Groleau @ 2003-05-30 2:50 UTC (permalink / raw) >>Mário Amado Alves wrote: >>>Everybody wants class MI. The reasons it was left out of Ada 95 and I don't! -- Nobody ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 2:50 ` Wesley Groleau @ 2003-05-30 7:38 ` Dmitry A. Kazakov 2003-05-30 12:20 ` Karel Miklav 2003-05-30 8:28 ` Mário Amado Alves 1 sibling, 1 reply; 73+ messages in thread From: Dmitry A. Kazakov @ 2003-05-30 7:38 UTC (permalink / raw) Wesley Groleau wrote: >>>Mário Amado Alves wrote: >>>>Everybody wants class MI. The reasons it was left out of Ada 95 and > > I don't! OK. Bill Gates once said that nobody would need more than 64K RAM. Or was it 640K? I do not remember. Anyway, never say never. (:-)) -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 7:38 ` Dmitry A. Kazakov @ 2003-05-30 12:20 ` Karel Miklav 2003-05-30 12:59 ` Hyman Rosen ` (2 more replies) 0 siblings, 3 replies; 73+ messages in thread From: Karel Miklav @ 2003-05-30 12:20 UTC (permalink / raw) Dmitry A. Kazakov wrote: > Wesley Groleau wrote: >>>>Mário Amado Alves wrote: >>>> >>>>>Everybody wants class MI. The reasons it was left out of Ada 95 and >> >>I don't! > > OK. Bill Gates once said that nobody would need more than 64K RAM. Or was it > 640K? I do not remember. Anyway, never say never. (:-)) I don't see how this is related to MI. What do you think about the diamond problem and other evils of MI? Besides, where do or would you use this feature? MI might look like a good idea in a simple project, but when things start to get messy and you're caught into inheritance net, you can forget who your own mother is :) I vote NO for MI and other inventions of marketing departments but YES for interfaces. Regards, Karel Miklav ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 12:20 ` Karel Miklav @ 2003-05-30 12:59 ` Hyman Rosen 2003-05-30 14:02 ` Georg Bauhaus 2003-05-30 19:31 ` Wojtek Narczynski 2003-05-30 22:42 ` John Griffiths 2003-05-31 9:27 ` Dmitry A. Kazakov 2 siblings, 2 replies; 73+ messages in thread From: Hyman Rosen @ 2003-05-30 12:59 UTC (permalink / raw) Karel Miklav wrote: > What do you think about the diamond problem and other evils of MI? What diamond problem? What other evils? ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 12:59 ` Hyman Rosen @ 2003-05-30 14:02 ` Georg Bauhaus 2003-05-30 14:04 ` Lutz Donnerhacke 2003-05-30 15:02 ` Hyman Rosen 2003-05-30 19:31 ` Wojtek Narczynski 1 sibling, 2 replies; 73+ messages in thread From: Georg Bauhaus @ 2003-05-30 14:02 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote: : Karel Miklav wrote: : > What do you think about the diamond problem and other evils of MI? : : What diamond problem? Parhaps class A { public: virtual int foo() = 0; }; class A1 : public A { public: virtual int foo(); }; // from library 1 class A2 : public A { public: virtual int foo(); }; // from library 2 class B : public A1, A2 { public: virtual int bar(); }; int B::bar() { foo(); } // which foo() here? -- Georg ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 14:02 ` Georg Bauhaus @ 2003-05-30 14:04 ` Lutz Donnerhacke 2003-05-30 18:45 ` Georg Bauhaus 2003-05-30 15:02 ` Hyman Rosen 1 sibling, 1 reply; 73+ messages in thread From: Lutz Donnerhacke @ 2003-05-30 14:04 UTC (permalink / raw) * Georg Bauhaus wrote: > Hyman Rosen <hyrosen@mail.com> wrote: >: Karel Miklav wrote: >: > What do you think about the diamond problem and other evils of MI? >: >: What diamond problem? > > Parhaps > > class A { > public: > virtual int foo() = 0; > }; > > class A1 : public A { public: virtual int foo(); }; // from library 1 > class A2 : public A { public: virtual int foo(); }; // from library 2 > > class B : public A1, A2 { You may stop here and ask for B.foo(). > public: > virtual int bar(); > }; > > int B::bar() { foo(); } // which foo() here? ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 14:04 ` Lutz Donnerhacke @ 2003-05-30 18:45 ` Georg Bauhaus 0 siblings, 0 replies; 73+ messages in thread From: Georg Bauhaus @ 2003-05-30 18:45 UTC (permalink / raw) Lutz Donnerhacke <lutz@iks-jena.de> wrote: : * Georg Bauhaus wrote: :> Hyman Rosen <hyrosen@mail.com> wrote: :>: Karel Miklav wrote: :>: > What do you think about the diamond problem and other evils of MI? :>: :>: What diamond problem? :> :> Parhaps :> :> class A { :> public: :> virtual int foo() = 0; :> }; :> :> class A1 : public A { public: virtual int foo(); }; // from library 1 :> class A2 : public A { public: virtual int foo(); }; // from library 2 :> :> class B : public A1, A2 { : : You may stop here and ask for B.foo(). Has been my intention, but also including the lower corner of the class diamond. Actually the call below does ask for B::foo() afaiks. What is B.foo()? : :> public: :> virtual int bar(); :> }; :> :> int B::bar() { foo(); } // which foo() here? : ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 14:02 ` Georg Bauhaus 2003-05-30 14:04 ` Lutz Donnerhacke @ 2003-05-30 15:02 ` Hyman Rosen 2003-05-30 19:14 ` Georg Bauhaus 1 sibling, 1 reply; 73+ messages in thread From: Hyman Rosen @ 2003-05-30 15:02 UTC (permalink / raw) Georg Bauhaus wrote: > int B::bar() { foo(); } // which foo() here? Neither one, since it's ambiguous, and the compiler will tell you that. But so what? If you really want to call one of them, you just say which one: int B::bar() { A2::foo(); } If you need to disambiguate the two for further inheritance, you rename and forward: struct A1_r : public A1 { virtual int foo_A1() { return A1::foo(); } int foo() { return foo_A1(); } }; struct A2_r : public A2 { virtual int foo_A2() { return A2::foo(); } int foo() { return foo_A2(); } }; struct B : A1_r, A2_r { int foo_A1(); // override A1's foo int foo_A2(); // override A2's foo }; ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 15:02 ` Hyman Rosen @ 2003-05-30 19:14 ` Georg Bauhaus 2003-05-30 19:40 ` Hyman Rosen 0 siblings, 1 reply; 73+ messages in thread From: Georg Bauhaus @ 2003-05-30 19:14 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote: : Georg Bauhaus wrote: :> int B::bar() { foo(); } // which foo() here? : : Neither one, since it's ambiguous, and the compiler : will tell you that. yes. : But so what? Some people have expressed disklike of this feature, at least they complain about the similar facility in Eiffel. I don't know why it is called a problem though, if MI isn't. Is there a mathematical problem of the same name in geometry? <ot>Incidentally, CLOS has precedence rules, afaics; but can programmers decide themselves, in CLOS, how to disambiguate?</> -- Georg ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 19:14 ` Georg Bauhaus @ 2003-05-30 19:40 ` Hyman Rosen 0 siblings, 0 replies; 73+ messages in thread From: Hyman Rosen @ 2003-05-30 19:40 UTC (permalink / raw) Georg Bauhaus wrote: > Some people have expressed disklike of this feature As with Ada, many people fear what they do not understand. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 12:59 ` Hyman Rosen 2003-05-30 14:02 ` Georg Bauhaus @ 2003-05-30 19:31 ` Wojtek Narczynski 1 sibling, 0 replies; 73+ messages in thread From: Wojtek Narczynski @ 2003-05-30 19:31 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<1054299592.913465@master.nyc.kbcfp.com>... > Karel Miklav wrote: > > What do you think about the diamond problem and other evils of MI? > > What diamond problem? The classic diamond problem they teach on at intermediate C++ courses. >What other evils? Ambiguous upcasting. Regards, Wojtek ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 12:20 ` Karel Miklav 2003-05-30 12:59 ` Hyman Rosen @ 2003-05-30 22:42 ` John Griffiths 2003-05-31 9:27 ` Dmitry A. Kazakov 2 siblings, 0 replies; 73+ messages in thread From: John Griffiths @ 2003-05-30 22:42 UTC (permalink / raw) <snip> "Karel Miklav" <karel@inetis.spppambait.com> wrote in message news:b0IBa.494$78.11159@news.siol.net... I vote NO for MI and other inventions of marketing departments but YES for interfaces. </snip> Has anyone done any work on defining interfaces for task types? Regards John ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 12:20 ` Karel Miklav 2003-05-30 12:59 ` Hyman Rosen 2003-05-30 22:42 ` John Griffiths @ 2003-05-31 9:27 ` Dmitry A. Kazakov 2003-05-31 13:53 ` Martin Krischik 2 siblings, 1 reply; 73+ messages in thread From: Dmitry A. Kazakov @ 2003-05-31 9:27 UTC (permalink / raw) Karel Miklav wrote: > Dmitry A. Kazakov wrote: >> Wesley Groleau wrote: >>>>>Mário Amado Alves wrote: >>>>> >>>>>>Everybody wants class MI. The reasons it was left out of Ada 95 and >>> >>>I don't! >> >> OK. Bill Gates once said that nobody would need more than 64K RAM. Or was >> it 640K? I do not remember. Anyway, never say never. (:-)) > > I don't see how this is related to MI. What do you think about the > diamond problem and other evils of MI? Incest? A bad thing, you know. However, I would not call a problem anything that can be detected at compile-time. Anyway we have a lot of diamond-things in present Ada. Consider: with Ada.IO_Exceptions; package B is End_Error : exception renames IO_Exceptions.End_Error; ... end B; with Ada.IO_Exceptions; package C is End_Error : exception renames IO_Exceptions.End_Error; ... end C; with B; use B; with C; use C; procedure D is ... exception when End_Error => -- which End_Error? exception renaming is not 'renaming', but a new view. In C++ terms it is sort of "B : public A", not "B : public virtual A" (as a naive programmer might think). > Besides, where do or would you use this feature? First from the stack: to make a stream object controlled. (*) > MI might look like a good idea in a simple project, but when things > start to get messy and you're caught into inheritance net, you can > forget who your own mother is :) I vote NO for MI and other inventions > of marketing departments but YES for interfaces. (*) Ada.Streams.Root_Stream_Type is not a [public] descendant of Ada.Finalization.Limited_Controlled. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-31 9:27 ` Dmitry A. Kazakov @ 2003-05-31 13:53 ` Martin Krischik 2003-06-01 9:18 ` Dmitry A. Kazakov 0 siblings, 1 reply; 73+ messages in thread From: Martin Krischik @ 2003-05-31 13:53 UTC (permalink / raw) Dmitry A. Kazakov wrote: > Karel Miklav wrote: > >> Dmitry A. Kazakov wrote: >> I don't see how this is related to MI. What do you think about the >> diamond problem and other evils of MI? > > Incest? A bad thing, you know. However, I would not call a problem > anything that can be detected at compile-time. -- The Problem is not detecting it. The problem is alowing it. Even in real live it is eventualy allowed (usualy from 2nd level cousins onwards). If you don't allow it you will sooner or later run into real limitations - beeing unable to combine just the right parents to form just the right child. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-31 13:53 ` Martin Krischik @ 2003-06-01 9:18 ` Dmitry A. Kazakov 0 siblings, 0 replies; 73+ messages in thread From: Dmitry A. Kazakov @ 2003-06-01 9:18 UTC (permalink / raw) Martin Krischik wrote: > Dmitry A. Kazakov wrote: > >> Karel Miklav wrote: >> >>> Dmitry A. Kazakov wrote: > >>> I don't see how this is related to MI. What do you think about the >>> diamond problem and other evils of MI? >> >> Incest? A bad thing, you know. However, I would not call a problem >> anything that can be detected at compile-time. -- > > The Problem is not detecting it. The problem is alowing it. Even in real > live it is eventualy allowed (usualy from 2nd level cousins onwards). If > you don't allow it you will sooner or later run into real limitations - > beeing unable to combine just the right parents to form just the right > child. I cannot follow whether you are pro or contra. (:-)) Anyway, if a problem is detectable it can be solved. Inheritance through several paths (diamond) is not a problem but a case. Both variants of its interpretation has a place: 1. When objects have some reference count for garbage collection then one might wish only one instance of the count inherited. 2. When objects are derived from some list element, it is better to keep the instances separate to let the object be member of several lists. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-30 2:50 ` Wesley Groleau 2003-05-30 7:38 ` Dmitry A. Kazakov @ 2003-05-30 8:28 ` Mário Amado Alves 1 sibling, 0 replies; 73+ messages in thread From: Mário Amado Alves @ 2003-05-30 8:28 UTC (permalink / raw) Wesley Groleau wrote: > >>Mário Amado Alves wrote: > >>>Everybody wants class MI. The reasons it was left out of Ada 95 and > I don't! Please see my answer in thread "MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance)" --MAA ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) 2003-05-29 9:17 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Dmitry A. Kazakov 2003-05-29 22:56 ` MI in Ada 200X Hyman Rosen 2003-05-30 2:50 ` Wesley Groleau @ 2003-05-30 8:46 ` Preben Randhol 2003-05-31 10:17 ` Dmitry A. Kazakov 2 siblings, 1 reply; 73+ messages in thread From: Preben Randhol @ 2003-05-30 8:46 UTC (permalink / raw) Dmitry A. Kazakov wrote: > > Hey, the burden of proof is on your side! (:-)). SI is an artificially MI is not in Ada95. You want MI in Ada2005[*] and your reason is that since we have A (SI) we must have B (MI)? :-) [*] I sure hope it is not called Ada05 -- Preben Randhol http://www.pvv.org/~randhol/ ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) 2003-05-30 8:46 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Preben Randhol @ 2003-05-31 10:17 ` Dmitry A. Kazakov 2003-05-31 13:48 ` Preben Randhol 0 siblings, 1 reply; 73+ messages in thread From: Dmitry A. Kazakov @ 2003-05-31 10:17 UTC (permalink / raw) Preben Randhol wrote: > Dmitry A. Kazakov wrote: >> >> Hey, the burden of proof is on your side! (:-)). SI is an artificially > > MI is not in Ada95. You want MI in Ada2005[*] and your reason is that > since we have A (SI) we must have B (MI)? :-) If you have said "A", you should also say "B". (:-)) If a language should have inheritance, then it should be MI. But I also want multiple dispatch, and full ADT, and all types tagged (including tasks and protected types), and ... So I do not expect it in 2005. Sigh. > [*] I sure hope it is not called Ada05 Ada XP? (:-)) -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) 2003-05-31 10:17 ` Dmitry A. Kazakov @ 2003-05-31 13:48 ` Preben Randhol 2003-05-31 17:21 ` Dmitry A. Kazakov 0 siblings, 1 reply; 73+ messages in thread From: Preben Randhol @ 2003-05-31 13:48 UTC (permalink / raw) Dmitry A. Kazakov wrote: > > If you have said "A", you should also say "B". (:-)) Why? > Ada XP? (:-)) Oh, god no! -- Preben Randhol http://www.pvv.org/~randhol/ ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) 2003-05-31 13:48 ` Preben Randhol @ 2003-05-31 17:21 ` Dmitry A. Kazakov 0 siblings, 0 replies; 73+ messages in thread From: Dmitry A. Kazakov @ 2003-05-31 17:21 UTC (permalink / raw) Preben Randhol wrote: > Dmitry A. Kazakov wrote: >> >> If you have said "A", you should also say "B". (:-)) > > Why? Just a saying. >> Ada XP? (:-)) > > Oh, god no! We skipped Ada 2000 after Ada 95. OK if not, then either Activada or Ada#! (:-)) -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X 2003-05-28 13:57 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Mário Amado Alves 2003-05-28 15:05 ` Preben Randhol @ 2003-05-29 0:54 ` Hyman Rosen 2003-05-29 2:13 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Robert I. Eachus 2 siblings, 0 replies; 73+ messages in thread From: Hyman Rosen @ 2003-05-29 0:54 UTC (permalink / raw) M�rio Amado Alves wrote: > Everybody wants class MI. Java doesn't. C# doesn't. They're wrong, of course. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) 2003-05-28 13:57 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Mário Amado Alves 2003-05-28 15:05 ` Preben Randhol 2003-05-29 0:54 ` MI in Ada 200X Hyman Rosen @ 2003-05-29 2:13 ` Robert I. Eachus 2003-05-29 12:06 ` Mário Amado Alves 2 siblings, 1 reply; 73+ messages in thread From: Robert I. Eachus @ 2003-05-29 2:13 UTC (permalink / raw) M�rio Amado Alves wrote: > Everybody wants class MI. The reasons it was left out of Ada 95 and > 83, the cons, are weaker than the pros. So every Adaist whishes to see > it in Ada 200X. I must not be everybody. Ada currently supports the mix-in model of multiple inheritance. I sometimes have a type declaration followed by half a dozen mixins: type Visible is tagged private; private type Foo is abstract tagged record...end record; type Foo1 is new Mixin1(Foo,...); type Foo2 is new Mixin2(Foo1,...); type Foo3 is new Mixin3(Foo2,...); ... type Visible type is new MixinN(FooN,...); I've even used multiple instances of the same mixin, for example a sparse array implementation which used two instances of the same linked list package. (The matricies I was working with were sparse enough that walking a list was probably faster than using a tree index. But I could have added two AVL tree mixins if necessary with little change to the code.) The only problem I have with this approach is the need to come up with all those intermediate type names. (But the names are necessary, you have to use them in the calls to the various mixins. Even if you could use the name of the generic, it could be ambiguous, as in the sparse matrix example. But Bar(Foo2(Object)) calls the right Bar operation. I have no objection to adding the interface abstraction to Ada, but to me in is a solution to problems other than MI. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) 2003-05-29 2:13 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Robert I. Eachus @ 2003-05-29 12:06 ` Mário Amado Alves 2003-05-31 19:58 ` Chad R. Meiners 0 siblings, 1 reply; 73+ messages in thread From: Mário Amado Alves @ 2003-05-29 12:06 UTC (permalink / raw) ""Everybody wants class MI. The reasons it was left out of Ada 95 and 83, the cons, are weaker than the pros."" "Convince me :-) Seriously what are the pros and cons of MI." (Preben) The cons include the (aledged) "implementation burden" (Tucker Taft). "I must not be everybody. Ada currently supports the mix-in model of multiple inheritance." (Robert) Sure. I was talking about *class* MI. (Tucker calls it "linguistic".) The pros include "naturalness" of expression, occuring both at creation type Child is new Mother, Father; and at selection Do (A_Child.Mother_Feature) Do (A_Child.Father_Feature) And sure it's not "everybody" who wants it. But many folks do and recurrently voice it. It's an unsettled issue. Kind of as exceptions as tagged types (AE'2001). I guess it's Ada class wide programming felt as its most natural OO idiom. I wouldn't mind having it as an extension defined in a specialized annex. There is already a number of 'standard' Ada subsets (DSA, SPARK, Kernel Ada). Why not a superset? pragma Multiple_Inheritance (Child); -- :-) ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) 2003-05-29 12:06 ` Mário Amado Alves @ 2003-05-31 19:58 ` Chad R. Meiners 0 siblings, 0 replies; 73+ messages in thread From: Chad R. Meiners @ 2003-05-31 19:58 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 382 bytes --] "M�rio Amado Alves" <maa@liacc.up.pt> wrote in message news:4a4de33a.0305290406.567b7451@posting.google.com... > The pros include "naturalness" of expression, occuring both at > creation > > type Child is new Mother, Father; This expression is very unnatural since outside hermaphroditic species a child is by definition not substitutable for either a mother or father ;) ^ permalink raw reply [flat|nested] 73+ messages in thread
end of thread, other threads:[~2003-06-02 9:01 UTC | newest] Thread overview: 73+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-23 23:05 Suggestion for Ada 200x - Interface inheritance Steve 2003-05-24 1:02 ` Robert A Duff 2003-05-29 16:47 ` Brian Gaffney 2003-06-01 10:29 ` Craig Carey 2003-05-24 12:35 ` Wojtek Narczynski 2003-05-24 17:53 ` Georg Bauhaus 2003-05-25 13:11 ` Wojtek Narczynski 2003-05-24 22:07 ` Robert A Duff 2003-05-25 14:12 ` Wojtek Narczynski 2003-05-25 17:53 ` Jeffrey Carter 2003-05-25 18:47 ` Wesley Groleau 2003-05-25 19:42 ` Hyman Rosen 2003-05-26 7:53 ` Wojtek Narczynski 2003-05-26 15:50 ` Hyman Rosen 2003-05-27 18:41 ` Wojtek Narczynski 2003-05-27 18:55 ` Wesley Groleau 2003-05-27 19:13 ` Hyman Rosen 2003-05-28 13:07 ` Wojtek Narczynski 2003-05-28 13:28 ` Jean-Pierre Rosen 2003-05-29 0:58 ` Hyman Rosen 2003-05-28 22:13 ` Robert A Duff 2003-05-28 23:50 ` Hyman Rosen 2003-05-29 9:17 ` Dmitry A. Kazakov 2003-05-29 13:31 ` Wojtek Narczynski 2003-05-26 7:51 ` Wojtek Narczynski 2003-05-25 1:33 ` Steve 2003-05-25 10:37 ` Simon Wright 2003-05-26 7:54 ` Jean-Pierre Rosen 2003-05-26 10:07 ` Preben Randhol 2003-05-26 16:32 ` Pascal Obry 2003-05-26 16:59 ` Preben Randhol 2003-06-01 10:53 ` Craig Carey 2003-06-01 12:17 ` Preben Randhol 2003-05-26 7:49 ` Jean-Pierre Rosen 2003-06-02 9:01 ` Wojtek Narczynski 2003-05-28 13:57 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Mário Amado Alves 2003-05-28 15:05 ` Preben Randhol 2003-05-29 0:54 ` MI in Ada 200X Hyman Rosen 2003-05-29 17:38 ` Stephen Leake 2003-05-30 7:20 ` Preben Randhol 2003-05-29 9:17 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Dmitry A. Kazakov 2003-05-29 22:56 ` MI in Ada 200X Hyman Rosen 2003-05-30 7:39 ` Dmitry A. Kazakov 2003-05-30 13:11 ` Hyman Rosen 2003-05-30 14:29 ` Robert A Duff 2003-05-30 14:51 ` Hyman Rosen 2003-05-30 15:11 ` Mark A. Biggar 2003-05-30 15:51 ` Hyman Rosen 2003-05-30 22:38 ` John Griffiths 2003-05-30 2:50 ` Wesley Groleau 2003-05-30 7:38 ` Dmitry A. Kazakov 2003-05-30 12:20 ` Karel Miklav 2003-05-30 12:59 ` Hyman Rosen 2003-05-30 14:02 ` Georg Bauhaus 2003-05-30 14:04 ` Lutz Donnerhacke 2003-05-30 18:45 ` Georg Bauhaus 2003-05-30 15:02 ` Hyman Rosen 2003-05-30 19:14 ` Georg Bauhaus 2003-05-30 19:40 ` Hyman Rosen 2003-05-30 19:31 ` Wojtek Narczynski 2003-05-30 22:42 ` John Griffiths 2003-05-31 9:27 ` Dmitry A. Kazakov 2003-05-31 13:53 ` Martin Krischik 2003-06-01 9:18 ` Dmitry A. Kazakov 2003-05-30 8:28 ` Mário Amado Alves 2003-05-30 8:46 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Preben Randhol 2003-05-31 10:17 ` Dmitry A. Kazakov 2003-05-31 13:48 ` Preben Randhol 2003-05-31 17:21 ` Dmitry A. Kazakov 2003-05-29 0:54 ` MI in Ada 200X Hyman Rosen 2003-05-29 2:13 ` MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance) Robert I. Eachus 2003-05-29 12:06 ` Mário Amado Alves 2003-05-31 19:58 ` Chad R. Meiners
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox