Suggestion for Ada 200x - Interface inheritance

Suggestion for Ada 200x - Interface inheritance

[Steve]

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)

Re: Suggestion for Ada 200x - Interface inheritance

[Robert A Duff]

"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

Re: Suggestion for Ada 200x - Interface inheritance

[Brian Gaffney]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Craig Carey]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

"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

Re: Suggestion for Ada 200x - Interface inheritance

[Georg Bauhaus]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Robert A Duff]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Jeffrey Carter]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Wesley Groleau]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Hyman Rosen]

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.

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Hyman Rosen]

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.

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Wesley Groleau]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Hyman Rosen]

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.

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

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.

Re: Suggestion for Ada 200x - Interface inheritance

[Jean-Pierre Rosen]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Hyman Rosen]

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.

Re: Suggestion for Ada 200x - Interface inheritance

[Robert A Duff]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Hyman Rosen]

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.

Re: Suggestion for Ada 200x - Interface inheritance

[Dmitry A. Kazakov]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Steve]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Simon Wright]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Jean-Pierre Rosen]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Preben Randhol]

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/

Re: Suggestion for Ada 200x - Interface inheritance

[Pascal Obry]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Preben Randhol]

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/

Re: Suggestion for Ada 200x - Interface inheritance

[Craig Carey]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Preben Randhol]

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/

Re: Suggestion for Ada 200x - Interface inheritance

[Jean-Pierre Rosen]

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

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

"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

MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance)

[Mário Amado Alves]

"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"? ;-)

Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance)

[Preben Randhol]

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/

Re: MI in Ada 200X

[Hyman Rosen]

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.

Re: MI in Ada 200X

[Stephen Leake]

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

Re: MI in Ada 200X

[Preben Randhol]

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/

Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance)

[Dmitry A. Kazakov]

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

Re: MI in Ada 200X

[Hyman Rosen]

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.

Re: MI in Ada 200X

[Dmitry A. Kazakov]

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

Re: MI in Ada 200X

[Hyman Rosen]

Dmitry A. Kazakov wrote:
 > There is other way, I hope.

I feel certain that your way will never be adopted.

Re: MI in Ada 200X

[Robert A Duff]

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

Re: MI in Ada 200X

[Hyman Rosen]

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.

Re: MI in Ada 200X

[Mark A. Biggar]

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

Re: MI in Ada 200X

[Hyman Rosen]

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.

Re: MI in Ada 200X

[John Griffiths]

<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

Re: MI in Ada 200X

[Wesley Groleau]

>>Mário Amado Alves wrote:
>>>Everybody wants class MI. The reasons it was left out of Ada 95 and

I don't!

-- 
Nobody

Re: MI in Ada 200X

[Dmitry A. Kazakov]

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

Re: MI in Ada 200X

[Karel Miklav]

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

Re: MI in Ada 200X

[Hyman Rosen]

Karel Miklav wrote:
 > What do you think about the diamond problem and other evils of MI?

What diamond problem? What other evils?

Re: MI in Ada 200X

[Georg Bauhaus]

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

Re: MI in Ada 200X

[Lutz Donnerhacke]

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

Re: MI in Ada 200X

[Georg Bauhaus]

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

Re: MI in Ada 200X

[Hyman Rosen]

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

Re: MI in Ada 200X

[Georg Bauhaus]

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

Re: MI in Ada 200X

[Hyman Rosen]

Georg Bauhaus wrote:
> Some people have expressed disklike of this feature

As with Ada, many people fear what they do not understand.

Re: MI in Ada 200X

[Wojtek Narczynski]

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

Re: MI in Ada 200X

[John Griffiths]

<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

Re: MI in Ada 200X

[Dmitry A. Kazakov]

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

Re: MI in Ada 200X

[Martin Krischik]

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

Re: MI in Ada 200X

[Dmitry A. Kazakov]

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

Re: MI in Ada 200X

[Mário Amado Alves]

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

Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance)

[Preben Randhol]

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/

Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance)

[Dmitry A. Kazakov]

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

Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance)

[Preben Randhol]

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/

Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance)

[Dmitry A. Kazakov]

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

Re: MI in Ada 200X

[Hyman Rosen]

M�rio Amado Alves wrote:
> Everybody wants class MI.

Java doesn't. C# doesn't. They're wrong, of course.

Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance)

[Robert I. Eachus]

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.

Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance)

[Mário Amado Alves]

""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); -- :-)

Re: MI in Ada 200X (was: Suggestion for Ada 200x - Interface inheritance)

[Chad R. Meiners]

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