Re: friend classes in ada95

Re: friend classes in ada95

[swhalen]

Mathew Heaney has worked through many of the Patterns
in Ada95 over in the ACM Patterns Archive.

His "Iterator and Factory combined" is at

  http://www.acm.org/archives/wa.cgi?A2=ind9811&L=patterns&F=&S=&P=100
 
Steve


-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

friend classes in ada95

[Stefan Folkesson]

In ADA95, is there a way to make the private part of one class
accessable from another (see friend classes in C++)? 

The reason I wonder this is because I want to apply the 'Iterator
Pattern' in my design. This demands that the Iterator object can access
the attributes of the Aggregate object.

Is this possible? Is there a pragma to supress the access check or do I
have to declare the attributes of the Aggregate class in the public part
of the specification.

/Stefan

Re: friend classes in ada95

[Stefan Folkesson]

Yes, this is what I've done so far, but I'd rather like to separate the
different classes logically in the file structure (1 class <==> 1 file).
I do not want to mix the operations for two objects in the same package.

Another approach I have considered is to let the Iterator package be a
child package to Aggregate (the Iterator type does not inherit from the
Aggregate type)

package Aggregate is

  type T_Aggregate is private;

private
  .   .   .
end Aggregate;

package Aggregate.Iterator is

  type T_Iterator is private;

private
  .   .   .
end Aggregate.Iterator;

This would work, I think, but I want to consider other alternatives if
there are any.

/Stefan

Re: friend classes in ada95

[Julian Day]

Stefan Folkesson wrote:

> In ADA95, is there a way to make the private part of one class
> accessable from another (see friend classes in C++)?
>

The technique to use is a hierarchical package structure.

package X is
    ...
private
    ...
end X;

package X.Y is
    -- Cannot see X's private part
private
    -- Can see X's private part
end X.Y;

package body X.Y is
    -- Can see X's private part
end X.Y;

>
> The reason I wonder this is because I want to apply the 'Iterator
> Pattern' in my design. This demands that the Iterator object can access
> the attributes of the Aggregate object.
>

Ah, maybe what you really want is the Iterator procedure in your ADT to be
generic, like this:
generic
    with Do_Something ( Item : in out Item_Type);
proceudre Iterator (ADT : in out ADT_Type);

Then you can just instantiate it in your client with what ever procedure
you want...

>
> Is this possible? Is there a pragma to supress the access check or do I
> have to declare the attributes of the Aggregate class in the public part
> of the specification.

Please don't go down that road.

HTH,

Julian

>
>
>
> /Stefan
>

Re: friend classes in ada95

[Steve Folly]

"Julian Day" <julianday@geocities.com> wrote in message
news:38F6D9F0.F0DE08E4@geocities.com...
> Stefan Folkesson wrote:
>
> > In ADA95, is there a way to make the private part of one class
> > accessable from another (see friend classes in C++)?
> >
>
> The technique to use is a hierarchical package structure.
>
> package X is
>     ...
> private
>     ...
> end X;
>
> package X.Y is
>     -- Cannot see X's private part

Not true - according to the LRM (I forget which section off the top of my
head) child package visibility rules are the same as if you had declared (in
this case) Y inside X at the end of it's private part after all other
declarations.

> private
>     -- Can see X's private part
> end X.Y;
>
> package body X.Y is
>     -- Can see X's private part
> end X.Y;
>
<cut the rest>


--
Regards,
Steve Folly.
http://www.spfweb.co.uk/
donationsto:myaccount@mybank.co.uk
mailto:steve.folly@mail.com

Re: friend classes in ada95

[Robert A Duff]

"Steve Folly" <steve.folly@mail.com> writes:

> > package X.Y is
> >     -- Cannot see X's private part
> 
> Not true - according to the LRM (I forget which section off the top of my
> head) child package visibility rules are the same as if you had declared (in
> this case) Y inside X at the end of it's private part after all other
> declarations.

If you look up that section, you'll have trouble finding it.  ;-)

The visible part of a child cannot see the parent's private part,
unless it's a private child.

- Bob

Re: friend classes in ada95

[Florian Weimer]

Stefan Folkesson <stefan.folkesson@emw.ericsson.se> writes:

> The reason I wonder this is because I want to apply the 'Iterator
> Pattern' in my design. This demands that the Iterator object can access
> the attributes of the Aggregate object.

Can you declare Aggregate and Iterator in the same package?

Re: friend classes in ada95

[John J. Rusnak]

Stefan Folkesson wrote:

> In ADA95, is there a way to make the private part of one class
> accessable from another (see friend classes in C++)?
>
> The reason I wonder this is because I want to apply the 'Iterator
> Pattern' in my design. This demands that the Iterator object can access
> the attributes of the Aggregate object.
>
> Is this possible? Is there a pragma to supress the access check or do I
> have to declare the attributes of the Aggregate class in the public part
> of the specification.
>
> /Stefan

Yes, and no pragma is needed.

In fact,  a class has no control (that I am aware of) of who its "friends"
are.  The way to implement a friend relationship is to use a child
package.  A child package automatically has visibility into the private
parts of its parent's spec.  The implementation of a friend class through a
child package does involve a tighter coupling of the class and its
"friend", but this is a good thing.  One should only implement a friend
relationship if there is a strong need (and a need for strong coupling
between the classes).

-John

Re: friend classes in ada95

[Jeff Carter]

Stefan Folkesson wrote:
> 
> In ADA95, is there a way to make the private part of one class
> accessable from another (see friend classes in C++)?

From ARM N.6:

Class.  A class is a set of types that is closed under derivation, which
means that if a given type is in the class, then all types derived from
that type are also in the class. The set of types of a class share
common properties, such as their primitive operations.

Therefore, classes do not have private parts. Packages, protected types,
and task types have private parts.

Others have answered the intent of your question ([private] child
packages). I would just like to say that if you try to write C++ in Ada
you will find it as ugly and difficult as trying to write Ada in C++.

In C++, the class construct provides for type definition and extension,
encapsulation, and information hiding. In Ada, packages provide for
modularity, encapsulation, and information hiding, while the type system
provides for type definition and extension.

> Is this possible? Is there a pragma to supress the access check or do 

In general, unless you are doing something very low level, if you are
considering suppressing or bypassing the language checks then you are
going about something the wrong way.
-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail

Re: friend classes in ada95

[Robert Dewar]

In article <38F887AE.8CDA24E0@acm.org>,
  jrcarter@acm.org wrote:
> Stefan Folkesson wrote:
> >
> > In ADA95, is there a way to make the private part of one
class
> > accessable from another (see friend classes in C++)?
>
> From ARM N.6:
>
> Class.  A class is a set of types that is closed under
> derivation, which means that if a given type is in the class,
> then all types derived from that type are also in the class.
> The set of types of a class share common properties, such as
> their primitive operations.

Some interesting Ada history, probably not known to many
readers of this list, since it's quite a while ago now :-)

It's always a hard sell when you choose terminology that is
arbitrarily different from the cultural norm. It is interesting
to recall the big debate at the Salem meeting between Tucker
Taft and Jean Ichibiah.

Jean argued that Ada 95 would be far more accessible to the
object oriented cognoscenti if it was willing to embrace the
term class more enthusiastically, and he suggested that

  type x is tagged record ....

be replaced by

  class type x is record ....

The distinguished reviewers had previously voted overwhelmingly
approving the idea that the term class should appear in the
declaration, although there was somewhat less enthusiasm for
the prefix notation (although of course it is quite consistent
with the notation used for task types and protected types).

Tucker argued strongly (one almost might say frantically :-)
that this was a bad idea, since class meant something different
in Ada 95.

The national delegations at Salem were all a bit appalled by
the ferocity of the argument on both sides, and in particular
at what was clearly a huge amount of effort the design team
had spent in preparing the counter argument.

The vote was even, with several countries abstaining, including
the US. The US abstention reflected substantial disagreement in
the US delegation (I can't rememeber everyone's individual
positions, and indeed it would not be appropriate for me to
divulge them in any case, but I can say I strongly supported
the use of the term CLASS in this context, and not suprisingly
Tucker strongly opposed it). The US delegation decided in
advance that it would support the winning side. When the vote
was tied, I got up and said:

"Since it would take a majority decision to undo a previous
decision, this means that the motion (to change to using class)
fails, and the US delegation therefore changes its vote to
opposed."

I knew perfectly well at the time that if I had instead said

"I really think we cannot have an important issue like this
left open with an even vote, I propose that we discuss
this further and revote, that then most likely CLASS would
have been approved."

But I worried about the dynamics. For whatever reason it
was clear that the Ada 95 design team was truly ferociously
opposed (in fact it reminded me of Jean's opposition to the
unanimous recommendation of the Ada 83 DR's for removing
derived types from Ada 83).

Jean's motion was rejected partly because he insisted on
the prefix notation. Indeed the Japanese delegation voted
against it solely on this basis, and I think if they had
realized that tactically their negative vote would sink
the whole proposal, they would have reconsidered. Even
if they had abstained, then the motion would have carried
(by a majority of 2 countries, since the US would then have
voted FOR the motion.)

I tried before the discussion to get Jean to separate the
two points, but he refused. I knew that was a
tactical error, based on previous discussions in the DR
group, but he was adamant. Personally I prefer the prefix
notation, but I knew others were quite opposed to it.

The history at that point is that Jean was so fed up with what
he felt was a significantly bad decision that would affect
acceptance of Ada 95 that he gave up on participation in the
design effort.

All water under the bridge of course, but everytime I see the
kind of confusion that this decision causes among OO folks
seeing Ada for the first time, I wonder whether the DR's who
voted in favor of putting CLASS into the declaration and doing
away with TAGGED might have been right.

I think Jean was wrong in his fear that this "mistake" would
cause major disaffectation with Ada 95, and I think that history
has shown that this was not the case, but still the odd word
TAGGED still does cause a lot of raised eyebrows for people
coming to the language for the first time.

There are many other intersting stories in the Ada 95 design
process, but the Salem vote on class was probably the high
point in drama :-)

If any of the other participants wish to add details, or correct
me if they think I got any details wrong, feel free (it's quite
a while ago and perhaps I have forgotten some details).

Robert Dewar


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Jeff Carter]

Robert Dewar wrote:
[discussion of the debate and vote on "class" v "tagged" deleted]
> There are many other intersting stories in the Ada 95 design
> process, but the Salem vote on class was probably the high
> point in drama :-)

Personally I find this kind of history interesting. All I saw at the
time was Ichbiah's article on "Ada with null", which did not help me
understand very well his objections that lead to his leaving the
revision process entirely.

Too bad there isn't a web site with all this history that weirdoes like
me could read.

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail

Re: friend classes in ada95

[David Botton]

If I had the time I would modify GNAT even if just for my own use to add
support for something like:

class type X is new Y with
    interface
        A, B
    record
        new_var : abc;
    end record;

and

interface type ABC;

procedure A_Func (This : ABC) is abstract;

interface type DEF is new ABC;

procedure B_Func (This : ABC) is abstract;

You could then have vars like:

A : ABC'Class := An_X object;

type ABC_Pointer is access all ABC'Class;

I would have a syntax for OO that was not embarassing to talk about in
public and would stop turning purple when confronted by OO people about MI
since I have at least interface inheritance _directly_ suported by the
language.

On Win32 I would implement the interfaces using the same "vtbl" style used
by MSVC++ and therefore COM.

Perhaps some day......

(Ok, enough day dreaming, I've got to get back to work...)

David Botton


Robert Dewar wrote in message <8dc8oi$kda$1@nnrp1.deja.com>...
>  class type x is record ....

Re: friend classes in ada95

[David Botton]

Most of the time when articles of this nature are posted and I ask for
permission to put them up on AdaPower, I get negative responces. Even though
I feel that it is important to understand these points and other points of
history to be a supportive member of the Ada community who came after the 83
and 95 process has long since past, I can respect that many people take
issues to heart and putting them on a web page only serves to resurface hard
feelings.

David Botton

Jeff Carter wrote in message <38F9F4E5.10C13CAD@acm.org>...

>Too bad there isn't a web site with all this history that weirdoes like
>me could read.

Re: friend classes in ada95

[Robert Dewar]

In article <rBnK4.4959$I75.3624892@news-east.usenetserver.com>,
  "David Botton" <David@Botton.com> wrote:
> Most of the time when articles of this nature are posted and I
ask for
> permission to put them up on AdaPower, I get negative
responces. Even though
> I feel that it is important to understand these points and
other points of
> history to be a supportive member of the Ada community who
came after the 83
> and 95 process has long since past, I can respect that many
people take
> issues to heart and putting them on a web page only serves to
resurface hard
> feelings.
>
> David Botton
>

It is not just that, it is that copyrighted articles posted
to newsgroups (yes, they are all copyrighted by default, that's
the way the copyright law works) are often informal opinions
and descriptions, not edited or checked, and not suitable for
republication. In the context of an original usenet discussion
they are taken in context, but when republished in another
forum, they can take on the unwelcome appearence of carefully
thought out articles, or statements of fact :-)

Note that posting an article on a newsgroup can never be taken
as implicit permission to republish in any other context. To do
so is a clear violation of the copyright law.

Of course, David is always very careful to ask for permission,
and he takes great care to make sure that adapower has only
articles which can be appropriately republished, but it does
not surprise me that many people are reluctant to see their
informal off-the-cuff posts to threads be elevated to the
status of permanently-preservable articles :-)



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert Dewar]

In article <mvnK4.4943$I75.3573293@news-east.usenetserver.com>,
  "David Botton" <David@Botton.com> wrote:

> class type X is new Y with
>     interface
>         A, B
>     record
>         new_var : abc;
>     end record;

I can't even guess what the intention is here I must admit,
this seems completely obscure to me.


> I would have a syntax for OO that was not embarassing to talk
> about in public and would stop turning purple when confronted
> by OO people about MI since I have at least interface
> inheritance _directly_ suported by the
> language.

I find your proposal very confusing, and I perfectly understand
interface inheritance. I think you need to properly fill out
your proposal and describe it in RM terms so that we can have
some chance of understanding what you are talking about.

It looks like a real mishmash of ideas to me, but perhaps that's
because it is unclear.

> On Win32 I would implement the interfaces using the same
> "vtbl" style used by MSVC++ and therefore COM.

Well tagged types use this *identical* implementation approach
so I really can't understand the distinction you are trying
to make here.

Just to be clear, Jean's proposal was a simple syntactic
transformation, completely unrelated (I think :-) to David's
sketch here.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert Dewar]

In article <t766tgsjeq.fsf@calumny.jyacc.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
> > it does not surprise me that many people are reluctant to
see their
> > informal off-the-cuff posts to threads be elevated to the
status of
> > permanently-preservable articles
>
> Considering that you post from deja.com, I'm surprised that
> you didn't add that such reluctance is entirely futile.

Sorry, I don't understand. It is one thing to have the posts
preserved as contributions to the newsgroup, but I (and the law)
would consider it a violation of my copyright if someone were
to publish articles in another context, such as a printed
journal.

So you misunderstood what I was saying. I think of what I
write here as simply newsgroup posts, not journal articles :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[David Botton]

The relation to Jean's proposal is the use of the prefix class instead of
tagged.

My additions if I can relate them well enough for some one to understand
(and perhaps that person would re-write it in a more formal language that
captures the idea, as I am lacking in that department, but always ready to
work on it.) are:

The interface section :

class type X is new Y with
     interface
         A, B
     record
         new_var : abc;
     end record;

This designates that class type X (aka tagged type X) implements interfaces
A and B. It also states that objects of class type X may be cast to objects
of type A'Class and B'Class where A and B are (see below) interface types.

The interface type:

interface type A;
or
interface type A is new F;

This designates an abstract tagged type used to define the subprograms for
the interface.

David Botton


Robert Dewar <robert_dewar@my-deja.com> wrote in message
news:8df6fb$mm3$1@nnrp1.deja.com...

> I find your proposal very confusing, and I perfectly understand
> interface inheritance. I think you need to properly fill out
> your proposal and describe it in RM terms so that we can have
> some chance of understanding what you are talking about.
>
> It looks like a real mishmash of ideas to me, but perhaps that's
> because it is unclear.

Re: friend classes in ada95

[David Botton]

The format / approach of the tagged type doesn't matter to me. It is the
interfaces format that matters.

What I would like to do would look something like this in today's Ada with a
twist:

-- Interface IUnknown
type IUnknown is abstract tagged null record;
--  I like the prefix idea so I would use:  interface type IUnknown;

type PUnknown is access all IUnknown;

function QueryInterface (This : IUnknown, etc ...) return Interfaces.C.long
is abstract;
pragma Convention (C, QueryInterface);

function AddRef (This : IUnknown) return Interfaces.C.unsigned is abstract;
pragma Convention (C, AddRef);

function Release (This : IUnknown) return Interfaces.C.unsigned  is
abstract;
pragma Convention (C, Release);

-- Interface IBeep
type IBeep is new abstract IUnknown with null record;
--  I want to be able to extend interface definitions so I need something
that does this
--  I would put here:  interface type IBeep is new IUnknown;
type PBeep is access all IBeep;

function Beep (This : IBeep) return Interfaces.C.unsigned is abstract;
pragma Convention (C, Beep);

-- Interface IMessage
type IMessage  is new abstract IUnknown with null record;
type PMessage is access all IMessage;

function Message (This : IMessage) return Interfaces.C.unsigned is abstract;
pragma Convention (C, Beep);

type Beep_Class is tagged

-- class type Beep_Class is  would be so much nicer here.

-- Some how designate that Beep_Class implements IBeep and IMessage say with
the interface section I mentioned like:
--  Interface
--      IBeep, IMessage

    record
        Ref_Count : Interfaces.C.long;
    end record;

-- Implements  IUnknown for both IBeep and IMessage
function QueryInterface (This : Beep_Class, etc ...) return
Interfaces.C.long;
function AddRef (This : Beep_Class) return Interfaces.C.unsigned;
function Release (This : Beep_Class) return Interfaces.C.unsigned;

-- Implements IBeep
function Beep (This : Beep_Class) return Interfaces.C.unsigned;

-- Implements IMessage
function Message (This : IMessage) return Interfaces.C.unsigned;


The I could do:

P1 : PUnknown := new Beep_Class;
P2 : PMessage := PMessage (P1);
P3 : PBeep := PBeep (P1);

hr := AddRef (P1);
hr := Beep (P2);

etc.

I would then make P1 guts look like a pointer to:

    record
        QueryInterface : System.Address;
        AddRef            : System.Address;
        Release            : System.Address;
        Object             : System.Address;
   end record;

P2 like

    record
        QueryInterface : System.Address;
        AddRef            : System.Address;
        Release            : System.Address;
        Beep                : System.Address;
        Object              : System.Address;
    end record;

etc.

Or comething like that where I could pass a pointer to a clean table of
functions. and still get back to my object when needed. The layout of
Beep_Class doesn't matter to me.

David Botton


Robert Dewar <robert_dewar@my-deja.com> wrote in message
news:8df6fb$mm3$1@nnrp1.deja.com...
> > On Win32 I would implement the interfaces using the same
> > "vtbl" style used by MSVC++ and therefore COM.
>
> Well tagged types use this *identical* implementation approach
> so I really can't understand the distinction you are trying
> to make here.

Re: friend classes in ada95

[Robert I. Eachus]

Robert Dewar wrote:
 
> It's always a hard sell when you choose terminology that is
> arbitrarily different from the cultural norm. It is interesting
> to recall the big debate at the Salem meeting between Tucker
> Taft and Jean Ichibiah.

   I won't even try to write a history of Ada 9X, even of just that
meeting,
but it certainly was a key point in the history of Ada.  There were
several issues that could have resulted in failure to reach concensus at
that meeting, but most of the sound and fury
was devoted to class vs. tagged.  (To me the silliest of the issues with
such potential was
about whether or not to allow leading underscores in identifiers...)

   I think that the reason that the classs vs. tagged debate got so
furious was that there were two different viewpoints, one technical and
one aesthetic.  Many of those arguing for class were unwilling to
discuss some of the technical problems with their alternatives, while
the tagged group was very reluctant to consider compromises without
through analysis.  The sense in which the tagged group "won" is that the
version finally accepted did not create unnecessary limitations, and
IMHO, the changed to the treatment of abstract made at a later Boston
meeting probably would not have been possible with the syntax proposed
by Jean Ichbiah.

   The way in which the Ada community as a whole lost is that the
current syntax is probably much uglier that it had to be.  Efforts to
ammend the proposals (before the Salem meeting) were looked on as
unacceptable compromises instead of "perfecting ammendments."  "type Foo
is Bar with begin null; end record;" did get cleaned up to "...with null
record;" then "...with null;"  But simply replacing the tagged keyword
with class was for some reason unacceptable to both sides...

> The national delegations at Salem were all a bit appalled by
> the ferocity of the argument on both sides, and in particular
> at what was clearly a huge amount of effort the design team
> had spent in preparing the counter argument.

  Tucker, do you have a copy of your Winnie the Pooh slides?  I think it
would be worth putting them on-line in some historical archive, and if
possible Jean Ichbiah's presentation as well.

  But everyone should remember that there were several dozen potential
show-stoppers discussed and resolved in Salem, and by Saturday?
afternoon we had a consensus which was then adopted unanimously as the
result of the conference.
 
> I knew perfectly well at the time that if I had instead said
> 
> "I really think we cannot have an important issue like this
> left open with an even vote, I propose that we discuss
> this further and revote, that then most likely CLASS would
> have been approved."
> 
> But I worried about the dynamics. For whatever reason it
> was clear that the Ada 95 design team was truly ferociously
> opposed (in fact it reminded me of Jean's opposition to the
> unanimous recommendation of the Ada 83 DR's for removing
> derived types from Ada 83).
> 
> Jean's motion was rejected partly because he insisted on
> the prefix notation. Indeed the Japanese delegation voted
> against it solely on this basis, and I think if they had
> realized that tactically their negative vote would sink
> the whole proposal, they would have reconsidered. Even
> if they had abstained, then the motion would have carried
> (by a majority of 2 countries, since the US would then have
> voted FOR the motion.)
> 
> I tried before the discussion to get Jean to separate the
> two points, but he refused. I knew that was a
> tactical error, based on previous discussions in the DR
> group, but he was adamant. Personally I prefer the prefix
> notation, but I knew others were quite opposed to it.
 
    If we had another day, I would have strongly supported you.  But
running out of time on the clock/calendar could have a significantly
adverse impact on the Ada 9X process.  (And I think that every night
that week I was up past midnight getting materials ready for the next
day.  MITRE was acting as host, and often subgroups met late at night
preparing wording to be voted on the next day.  We had a computer set up
with a laser printer and we thought, plenty of transparencies.  We
almost ran out on the last day, even though we had twice sent someone to
get more...)  Many of those attending the meeting felt that it was
vitally important that the meeting end with no major divisive issues
unresolved. (And I think I remember RBKD as one who felt this way.)  The
class/tagged issue had been discussed and resolved at an earlier
meeting, but Jean Ichbiah reopened the issue on-line.  There is nothing
wrong with this.  In many cases a technical problem will be found in a
"closed" decision, and it is necessary to re-open the issue to correct
it.  But when all the problems are known and have been discussed, as
they had been in this case at or before the Salem meeting, a decision
has to be made that is final.  It would have been nice to have a better
proposal on the table at Salem, but there are cases where the procedures
for reaching agreement limited the number of alternatives considered. 
And in this case, any compromise position would--and did--get attacked
from both sides, since they saw no reason to compromise, and politically
both extreme positions had to be represented in the final vote.

   Oh, and one other thing that most people miss about this issue. 
There are classes in Ada 83,
and there is a richer class structure in Ada 95 that has little or
nothing to do with tagged types.  (See the note at the end of Section
3.2 in the Ada95 RM.)  To change the meaning of class as a technical
term would require significant additional work by the Language Design
Team--unless they were allowed to unify the existing class hierarchy and
the new class constructs.  But this had been explicitly considered and
rejected much earlier in the design process.  So those arguing for class
as a keyword had to justify the extra effort.

Re: friend classes in ada95

[Hyman Rosen]

Robert Dewar <robert_dewar@my-deja.com> writes:
> it does not surprise me that many people are reluctant to see their
> informal off-the-cuff posts to threads be elevated to the status of
> permanently-preservable articles

Considering that you post from deja.com, I'm surprised that you didn't
add that such reluctance is entirely futile.

Re: friend classes in ada95

[John J. Rusnak]

Robert A Duff wrote:

> "Steve Folly" <steve.folly@mail.com> writes:
>
> > > package X.Y is
> > >     -- Cannot see X's private part
> >
> > Not true - according to the LRM (I forget which section off the top of my
> > head) child package visibility rules are the same as if you had declared (in
> > this case) Y inside X at the end of it's private part after all other
> > declarations.
>
> If you look up that section, you'll have trouble finding it.  ;-)
>
> The visible part of a child cannot see the parent's private part,
> unless it's a private child.
>
> - Bob

Under GNAT, I have made use of the fact that a child package can see its parent's
private part even if it is NOT a private child.  This could just be an error in
the compiler, though.  (I have seen this technique used for implementing
something simliar to "protected" elements in C++ or Java as well as friend
classes).

Does anyone have the section number?


-John

Re: friend classes in ada95

[Robert Dewar]

In article <38FB8556.4EACD391@earthlink.net>,
  "Robert I. Eachus" <rieachus@earthlink.net> wrote:
> (To me the silliest of the issues with
> such potential was
> about whether or not to allow leading underscores in
> identifiers...)

Silly enough for you to have forgotten the issue :-) The issue
was whether to treat underscores as letters in identifiers,
removing the restrictions on the use of underscores. Actually
the example most often used was a trailing underscore, but the
general ability to mirror c identifiers such as a__b was also
an issue.

> IMHO, the changed to the treatment of abstract made at a later
> Boston meeting probably would not have been possible with the
> syntax proposed by Jean Ichbiah.

That's plain wrong, or a misunderstanding, the notation

  class type x is record ...

as simply a syntactic transformation of

  type x is tagged record ...

is completely neutral with respect to such changes (indeed
an Ada 95 compiler today could if it liked accept the first
time as a source representation of the second form (though
this kind of stretching of the notion of source representation
is considered unsporting, even if allowed by the RM :-)

 To change the meaning of class as a technical
> term would require significant additional work by the Language
Design
> Team--unless they were allowed to unify the existing class
hierarchy and
> the new class constructs.  But this had been explicitly
considered and
> rejected much earlier in the design process.  So those arguing
for class
> as a keyword had to justify the extra effort.


TO use this as an argument against the class syntax suggestion
is allowing best to be the enemy of good. The class syntax
could perfectly well be introduced without changing the notion
of classes.

After all, to most Ada 95 programmers

  type x is tagged record ...

introduces a new class called x anyway, sure I know that is
not quite right, but there are lots of cases where informal
usage does not match the RM :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95 (long)

[tmoran]

> -- Interface IUnknown
> ...

How about making a hidden MSWindows COM object to serve as the nucleus
of a higher level Ada object instead of adding syntax to tell the
Ada compiler to create today's low level MS Windows binary to
access COM objects.

with Interfaces.C;
package COM_Stuff is

end COM_Stuff;

private package COM_Stuff.Types is
  type Reference_Count_Type is new Interfaces.C.Unsigned;
  type HResult is new Interfaces.C.Long;
end COM_Stuff.Types;


with COM_Stuff.Types;
 use COM_Stuff.Types;
private package COM_Stuff.IUnknown_Interface is

  type IUnknown is abstract tagged null record;

  type Interface_Pointer is access IUnknown'class;

  function QueryInterface (This : IUnknown;
                           RIID : Integer;
                           ppvObject: access Interface_Pointer)
    return HResult is abstract;

  function AddRef (This : IUnknown) return Reference_Count_Type is abstract;

  function Release (This : IUnknown) return Reference_Count_Type is abstract;

end COM_Stuff.IUnknown_Interface;

with COM_Stuff.Types,
     COM_Stuff.IUnknown_Interface;
 use COM_Stuff.Types;
private package COM_Stuff.IBeep_Interface is

  type IBeep is abstract new COM_Stuff.IUnknown_Interface.IUnknown
  with null record;

  function Beep (This : IBeep) return HResult is abstract;

end COM_Stuff.IBeep_Interface;

with COM_Stuff.Types,
     COM_Stuff.IUnknown_Interface;
 use COM_Stuff.Types;
private package COM_Stuff.IMessage_Interface is

  type IMessage is abstract new COM_Stuff.IUnknown_Interface.IUnknown
  with null record;

  function Message (This : IMessage) return HResult is abstract;

end COM_Stuff.IMessage_Interface;



with COM_Stuff.Types,
     COM_Stuff.IUnknown_Interface,
     COM_Stuff.IBeep_Interface,
     COM_Stuff.IMessage_Interface;
 use COM_Stuff.Types;
private package COM_Stuff.Beeper is

  type Beep_Interface_Part is new COM_Stuff.IBeep_Interface.IBeep
  with null record;
  function QueryInterface (This : Beep_Interface_Part;
                           RIID : Integer;
                           ppvObject: access Interface_Pointer)
    return HResult;
  function AddRef (This : Beep_Interface_Part) return Reference_Count_Type;
  function Release (This : Beep_Interface_Part) return Reference_Count_Type;
  function Beep (This : Beep_Interface_Part) return HResult;


  type Message_Interface_Part is new IMessage_Interface.IMessage with null record;
  function QueryInterface (This : Message_Interface_Part;
                           RIID : Integer;
                           ppvObject: access Interface_Pointer)
    return HResult;
  function AddRef (This : Message_Interface_Part) return Reference_Count_Type;
  function Release (This : Message_Interface_Part) return Reference_Count_Type;
  function Message (This : Message_Interface_Part) return HResult is abstract;

  type Beeper_Type is new COM_Stuff.IUnknown_Interface.IUnknown with record
    Beeper : aliased Beep_Interface_Part;
    Message: aliased Message_Interface_Part;
    Ref_Count : Reference_Count_Type := 0;
  end record;
  function QueryInterface (This : Beeper_Type;
                           RIID : Integer;
                           ppvObject: access Interface_Pointer)
    return HResult;
  function AddRef (This : Beeper_Type) return Reference_Count_Type;
  function Release (This : Beeper_Type) return Reference_Count_Type;

end COM_Stuff.Beeper;


-- package body COM_Stuff.Beeper;  -- TBD


---------- All the above to aid implementation of the Ada style:

with Ada.Finalization;
package COM_Stuff.Public_Beeper is

  type Beeper_Type is new Ada.Finalization.Limited_Controlled with private;

  procedure Beep(This : in out Beeper_Type);

  procedure Message(This : in out Beeper_Type);

private
  type Beeper_Type is new Ada.Finalization.Limited_Controlled with null record;
  -- encapsulate and hide the stuff to Create/Reference count/Destroy
  -- and handle thread safety for COM_Stuff.Beeper.Beeper_Type

  procedure Initialize(This : in out Beeper_Type);
  procedure Finalize(This : in out Beeper_Type);
end COM_Stuff.Public_Beeper;



-- allowing the programmer using this to write things like:

with COM_Stuff.Public_Beeper;
procedure Main is
begin
  if 2+2 = 4 then
    declare
      use COM_Stuff.Public_Beeper;
      Beeper : Beeper_Type;
    begin
      Beep(Beeper);
      Message(Beeper);
    end;
  end if;
end Main;

Re: friend classes in ada95

[Vincent Marciante]

John J. Rusnak wrote:
> 
> Robert A Duff wrote:
<snip>
> > If you look up that section, you'll have trouble finding it.  ;-)
> >
> > The visible part of a child cannot see the parent's private part,
> > unless it's a private child.
> >
> > - Bob
> 
> Under GNAT, I have made use of the fact that a child package can see its parent's
> private part even if it is NOT a private child.  

Is the _visible_ (non-private) part of the non-private child seeing the
parent's private part?  That would be a defect in the compiler. 

> This could just be an error in
> the compiler, though.  (I have seen this technique used for implementing
> something simliar to "protected" elements in C++ or Java as well as friend
> classes).
> 
> Does anyone have the section number?

No section says it because it is wrong - that is the joke. 
Check out 

  http://www.adapower.com/rationale/rat95-p1-2.html#8

> 
> -John

Re: friend classes in ada95 (long)

[David Botton]

GNATCOM already does that very well and its tools build all the code for you
from start finish, you just have to fill in the bodies for the COM objects.
As for using the COM objects you run BindCOM or use the dynamic interface,
and wiz bang you are on your way.

What I am looking to do is introduce interface MI in to Ada syntax. And if I
am already going to implement it, I might as well do it in a way that would
make it easier to write a COM object in raw Ada. I would still never suggest
any one try and write COM objects with out a framework like GNATCOM, much as
most people would never write COM objects in C++ with out ATL or MFC.

Of course, I can already do interface MI in Ada already, so this is really
just about syntax. I am not happy that Ada comes out looking bad in OO
circles, since most people can not bridge the gap from "class  X" to "type X
is tagged", even though there is none.

David Botton

<tmoran@bix.com> wrote in message
news:TSSK4.73$vE6.38666@news.pacbell.net...
> > -- Interface IUnknown
> > ...
>
> How about making a hidden MSWindows COM object to serve as the nucleus
> of a higher level Ada object instead of adding syntax to tell the
> Ada compiler to create today's low level MS Windows binary to
> access COM objects.

Re: friend classes in ada95

[David Botton]

That is what I like best about Ada's OO :-)

David Botton

Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> wrote in message
news:8dh37m$qef$2@wanadoo.fr...
> A tagged type is not a class. A tagged type is a programming construct
that
> can be used to build classes. This is what the building block approach is
> about.

Re: friend classes in ada95

[David Botton]

class type X = type X is tagged

Geoff Bull:
> class type X is record ...
> and means exactly the same as
> type X is tagged record ...

Yup.

>
> I.E. we would have two ways of doing the same thing.

Yup.

Re: friend classes in ada95

[John Rusnak]

I see!

So only the private part of a public child can access the private part
of its parent. I guess I never came across a situation where that was
necessary.

 This still represents a way to implement a friend-relationship in Ada,
though.  Although the public interface to a tagged type in a child
package cannot have visiblity into the parent, the implementation
defined in the body can.  This is usually what I find important on those
rare occasions when a "friend" is helpful.

-John

Re: friend classes in ada95

[John Rusnak]

C++ allows you to put many classes in one namespace and also allows you
to have inner classes which are concepts analogous to putting more than
one tagged type in a package.  Java's definition of a package is
essentially a grouped collection of classes. Java also allows you to
have inner classes (I believe) and also allows you to define more than
one class within a given file, although only one will be publicly
available for use outside the file.

Note that it is recommended in Ada as a matter of good style NOT to put
more than one tagged type in a package.  (See Section9.6 of the Styl
Guide).  And I have to agree with this design choice.  When I do have to
put a seond tagged type in a package, I generally place it within the
context of an internal (child?) package.

-John

Re: friend classes in ada95

[tmoran]

> A tagged type is not a class. A tagged type is a programming construct
  When first trying to understand this stuff, I personally found thinking
of a tag on a record etc to be much easier to understand than all the
OO stuff about classes and objects.  "class" and "object" are such
vague terms they convey little information. Also they are used for
a variety of *different* things (see mathematics, or MS's use of "class"
in COM).  OTOH, if one's intent is to certify membership in an
exclusive club by the use of code words known only to the members,
then "class" is as good as anything.

Re: friend classes in ada95

[Stanley R. Allen]

David Botton wrote:
> 
> Of course, I can already do interface MI in Ada already, so this is really
> just about syntax. I am not happy that Ada comes out looking bad in OO
> circles, since most people can not bridge the gap from "class  X" to "type X
> is tagged", even though there is none.
> 

If they can't bridge this gap, it may be because prejudice is in
the way.

If that's not the problem, then the barrier may be that they are
attempting to make a direct leap from the C++ (or Java) model to
Ada 95.  It's a common mistake C++ people make when learning Java,
and we've seen more than a few questions here on c.l.a reflecting
that kind of confusion.

I like the approach N. Cohen uses in the second edition of "Ada
as a Second Language" to present the topic -- building up a
complete picture of the Ada model based on a discussion of derived
types, leaving comparisons to other languages until the end.

-- 
Stanley Allen
mailto:Stanley_R_Allen-NR@raytheon.com

P.S.

I'm still waiting for a good, thorough book focused on advanced OO
programming in Ada 95.  The general Ada textbooks are mostly for
beginners.  The discussions in the Rationale are a good starting
point, but obviously every aspect of the topic could not be discussed
in the space provided there.  Matthew Heaney's patterns articles contain
many of the things one would like to see in an "OO techniques for Ada 95"
book.

Re: friend classes in ada95

[Geoff Bull]

David Botton wrote:
> 
> If I had the time I would modify GNAT even if just for my own use to add
> support for something like:
> 
> class type X is new Y with
>     interface
>         A, B
>     record
>         new_var : abc;
>     end record;
> 
> and

can this degenerate to (when not implementing an interface):
class type X is new Y with
    record
         new_var : abc;
    end record;
?
In this case the class keyword is not needed.
Also I am worried that you could write

class type X is record ...
and means exactly the same as
type X is tagged record ...

I.E. we would have two ways of doing the same thing.
Or, if they didn't do the same thing it would
become confusing as to when to use  "class type"
and when to use "type X is tagged"

 
> 
> interface type ABC;

You could also have:

   type ABC is interface;

It seems to me you can probably do this without introducing a new keyword.
This is off the top of my head without thinking through, but ... 
an abstract tagged type with a null record and abstract primitive
subprograms looks to me an awful lot like an interface.


   type ABC is abstract tagged null record; 
   procedure A_Func (This : ABC) is abstract;

   type DEF is abstract new ABC; 
   procedure B_Func (This : ABC) is abstract;

   type Y is tagged record ...
   type X is new X, ABC, DEF with  -- maximum of one non "interface" type
      record
         ...
      end record;


Ok, the idea of a new keyword is growing on me :-)

> I would have a syntax for OO that was not embarassing to talk about in
> public 

What is embarrassing about tagged types?
(at least we don't have the C++ rtti mess, or that abstract
virtual function syntax)

Presumably some people must have argued for compromise syntax:

   tagged type X is record


Cheers
Geoff

Re: friend classes in ada95

[Jean-Pierre Rosen]

Can't resist to provide my 0.02 on the tagged/class issue, or how I present
it in my courses.

A tagged type is not a class. A tagged type is a programming construct that
can be used to build classes. This is what the building block approach is
about.
A class in the usual OOP sense is a *design pattern*, where you put a tagged
type and its associated primitive operations (the methods) in a package
specification. Ada allows you to build other design patterns, that have no
equivalent in other languages, like putting several tagged types in a single
package (a bit like friends, but not exactly similar).

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: friend classes in ada95

[Pascal Obry]

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


Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> a �crit dans le message :
8dh37m$qef$2@wanadoo.fr...
> Can't resist to provide my 0.02 on the tagged/class issue, or how I
present
> it in my courses.
>
> A tagged type is not a class. A tagged type is a programming construct
that
> can be used to build classes. This is what the building block approach is
> about.
> A class in the usual OOP sense is a *design pattern*, where you put a
tagged
> type and its associated primitive operations (the methods) in a package
> specification. Ada allows you to build other design patterns, that have no
> equivalent in other languages, like putting several tagged types in a
single
> package (a bit like friends, but not exactly similar).
>

I completly agree with this view. The whole point is "building block" and
this
is how Ada has been design. Then designer can use the flexibility of Ada
to build whatever "design pattern" they need, one of them is the C++ or
Java "class".

This "building block" orientation of Ada has been very well presented by T.
Taft
at a conference in Paris some years ago.

Pascal.

--

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- T T I                                    |
--|                       Intranet: http://cln46gb            |
--| Bureau N-023            e-mail: p.obry@der.edf.fr         |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|         http://perso.wanadoo.fr/pascal.obry
--|
--|   "The best way to travel is by means of imagination"

Re: friend classes in ada95

[Steve Folly]

On Fri, 14 Apr 2000 19:12:45 GMT, Robert A Duff <bobduff@world.std.com> did
clatter that keyboard and type:

>"Steve Folly" <steve.folly@mail.com> writes:
>
>> > package X.Y is
>> >     -- Cannot see X's private part
>> 
>> Not true - according to the LRM (I forget which section off the top of my
>> head) child package visibility rules are the same as if you had declared (in
>> this case) Y inside X at the end of it's private part after all other
>> declarations.
>
>If you look up that section, you'll have trouble finding it.  ;-)
>
>The visible part of a child cannot see the parent's private part,
>unless it's a private child.
>
>- Bob

I stand corrected :-(


Steve.

Re: friend classes in ada95

[John J. Rusnak]

I'd have to weigh in on the opposite side.  "Class" and "object" are rather
easy terms to grasp.   And I can tell you through exeperience that the Ada
model has been difficult for many I have seen coming into the language to
grasp.  (Some with OO backgrounds and some without).  But to each their own
I suppose.

I agree with the comment on "code words", though.

-John



tmoran@bix.com wrote:

> > A tagged type is not a class. A tagged type is a programming construct
>   When first trying to understand this stuff, I personally found thinking
> of a tag on a record etc to be much easier to understand than all the
> OO stuff about classes and objects.  "class" and "object" are such
> vague terms they convey little information. Also they are used for
> a variety of *different* things (see mathematics, or MS's use of "class"
> in COM).  OTOH, if one's intent is to certify membership in an
> exclusive club by the use of code words known only to the members,
> then "class" is as good as anything.

Re: friend classes in ada95

[David Botton]

The first step is getting them to come over from other languages and/or to
think of Ada as even a possibility. The lack of the _code_word_ "class" is a
huge wall, and since the introduction of Java, the lack of direct support
for at least MI with interfaces is another.

David Botton

Geoff Bull wrote in message
>For people coming from other languages, changing the word tagged to class
>is going to help not zero.
>The problem they face is overcoming the assumptions they have made
>about how oo is implemented.

MI, was Re: friend classes in ada95

[tmoran]

> What I am looking to do is introduce interface MI in to Ada syntax.
> And if I am already going to implement it, I might as well do it in a
> way that would make it easier to write a COM object in raw Ada.

  I'm confused.  It seems you 1) want MI Interfaces; 2) want them in a
binary compatible way (at least on Windows) with COM; 3) but
"Inheritance and reusability are terms with specific meanins for the
developer of object-oriented code.  These terms refer to the capability
of deriving your own classes from the base classes, replacing methods
with customized versions, and adding methods of your own.  None of this
is available with respect to COM objects."  Visual C++ 5 Unleashed, p 510.

Re: friend classes in ada95

[Alfred Hilscher]

Robert Dewar wrote:
> Jean argued that Ada 95 would be far more accessible to the
> object oriented cognoscenti if it was willing to embrace the
> term class more enthusiastically, and he suggested that
> 
>   type x is tagged record ....
> 
> be replaced by
> 
>   class type x is record ....
> 

I would have preferred this notation too.
1. "class type t is ..."  and  "t'class"   would be more clear than  
"type t is tagged ..."   and   "t'class"
2. I have to write   task type t is    and not    type t is concurrent
...

Re: friend classes in ada95

[Jeff Susanj]

In OO a class is data and the operations associated with that data.
Therefore, Ada doesn't explicitly have classes because the data and the
operations are not explicitly bound together.  If we consider a class to be
the tagged record and all of those operations that have access to the tagged
record then viola, there is a class.


Jeff S.


Geoff Bull wrote in message <38FD1C9E.7C2B7756@research.canon.com.au>...
>"John J. Rusnak" wrote:
>>
>> I'd have to weigh in on the opposite side.  "Class" and "object" are
rather
>> easy terms to grasp.   And I can tell you through exeperience that the
Ada
>> model has been difficult for many I have seen coming into the language to
>> grasp.  (Some with OO backgrounds and some without).  But to each their
own
>> I suppose.
>>
>For people coming from other languages, changing the word tagged to class
>is going to help not zero.
>The problem they face is overcoming the assumptions they have made
>about how oo is implemented.

Re: friend classes in ada95

[tmoran]

>In OO a class is data and the operations associated with that data.
>Therefore, Ada doesn't explicitly have classes because the data and the
>operations are not explicitly bound together.
  "Defined in the same package spec, and the operations take a parameter
of the (tagged) type" isn't sufficiently explicitly bound together?

>If we consider a class to be the tagged record and all of those
>operations that have access to the tagged record then viola, there is a
>class.
  So any user of the tagged record, even if it's an application that
merely passes the object as a black box, is part of the class?
Or if "access to the tagged record" means "knows about and can
access the record's components", then everything in the package
body, and, if the tagged record is not "is private", but rather is in
the public part of the spec, then any application code, is part of
the class?

The dictionary definition of a class is a set of things grouped
together because of a common trait.  What is common to the
definition of a data layout, or a data record, and a set of
procedures?  One is passive data, the other is active code.  OTOH,
a collection of things all deriving from the same ancestor, and
thus sharing certain traits, the Ada usage of "class", clearly fits
the dictionary definition.

I guess a "proper" OOer would have to say "The class Mammalia,
nursing, and live birth, are a class".  Obfuscation, IMHO.

Re: friend classes in ada95 (long)

[Brian Rogoff]

On Tue, 18 Apr 2000, David Botton wrote:
> What I am looking to do is introduce interface MI in to Ada syntax. And if I
> am already going to implement it, I might as well do it in a way that would
> make it easier to write a COM object in raw Ada. I would still never suggest
> any one try and write COM objects with out a framework like GNATCOM, much as
> most people would never write COM objects in C++ with out ATL or MFC.
> 
> Of course, I can already do interface MI in Ada already, so this is really
> just about syntax. 

Hmmm. I find that interface MI is very clumsy in Ada. Are you saying that
you find it as easy in Ada as in Java? Somehow I think I must be
misunderstanding you; please give an example of interface MI in Ada. 

There was some work at grafting interface MI into C++, indeed I believe
that GNU C++ may still support the "signature" proposal of Russo and 
Baumgartner. I thought that stuff was neat, and hope something similar
finds its way into the next Ada.

Ada already handles implementation MI well enough IMO, with generics and
the access discriminant trick. 

> I am not happy that Ada comes out looking bad in OO
> circles, since most people can not bridge the gap from "class  X" to "type X
> is tagged", even though there is none.

I guess I am one of those people who, for the most part, liked the Ada
"tagged" keyword and syntax since I first learned it, so this kind of
change is uninteresting to me. 

-- Brian

Re: friend classes in ada95

[Ray Blaak]

Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> writes:
> I would have preferred this notation too.
> 1. "class type t is ..."  and  "t'class"   would be more clear than  
> "type t is tagged ..."   and   "t'class"
> 2. I have to write   task type t is    and not    type t is concurrent
> ...

And "protected type t", not "type t is protected". 

For that matter, given a protected type, one also writes t.Foo instead of
Foo(t).

I know people here feel strongly about the normal procedural syntax for method
calls, and it certainly helps to avoid problems, especially with defining
binary operations, but having been away from Ada for a while, and using
Delphi, C++, and Java, I have found I have changed my mind.

I am realizing the saying obj.Method is a more natural way of expressing how I
*think*. 

I like Delphi's way of doing OO:

  type TObject = class (ParentClass, Interface1, Interface2, ...)
  private
    attribute : Integer;
  public
    procedure Foo(v : Integer);
  end;

and then the implementations look like:

  procedure TObject.Foo(v : Integer);
  begin
    self.attribute := v;
  end;

I consider myself to be an experienced OO programmer, and at one time was an
expert Ada programmer, and I certainly "get" Ada's way of doing OO with tagged
types, but I find the syntax now for doing simple OO stuff tedious and not as
clear to the reader as it should be.

Multiple inheritance from interfaces should be easy. Declaring virtual methods
should be easy. In Ada, the caller decides if dispatching is desired by
ensuring a method call is in terms of a class wide parameter or not. I think
it should be the class implementor that decides, since if the caller gets it
wrong, it is a silent error.

Delphi's style makes overriding and polymorphism clear in the code:

  type TObject = class(TBaseObject)
    procedure Foo; override; // required if TBaseObject.Foo is virtual
    procedure DispatchOnMe; virtual;
  end;

Ada's style is the most "correct" since we have a true building block
approach, but I just wish the syntax was a little better.

I am spouting religious opinions to be sure, I generally like Ada very much,
and its OO style is now standardized and not going to change any time soon,
but I will still complain about it now and again.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: friend classes in ada95 (long)

[David Botton]

Brian Rogoff wrote in message ...
>Hmmm. I find that interface MI is very clumsy in Ada. Are you saying that
>you find it as easy in Ada as in Java? Somehow I think I must be
>misunderstanding you; please give an example of interface MI in Ada.


It certainly is not as easy, just that it can be done. I was saying that if
I had the time I would make a non-standard Ada if need be to make it easier
until some one high up there did.

With true respect, I am sure that you can create a better example then I.

>
>There was some work at grafting interface MI into C++, indeed I believe
>that GNU C++ may still support the "signature" proposal of Russo and
>Baumgartner. I thought that stuff was neat, and hope something similar
>finds its way into the next Ada.


Exactly what I would love to see happen.

>Ada already handles implementation MI well enough IMO, with generics and
>the access discriminant trick.


Agreed. I try and avoid implementation MI anyways when possible and like the
control of roll your own solutions for implementation MI.

David Botton

Re: friend classes in ada95 (long)

[Brian Rogoff]

On 19 Apr 2000, Hyman Rosen wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > There was some work at grafting interface MI into C++, indeed I believe
> > that GNU C++ may still support the "signature" proposal of Russo and 
> > Baumgartner. I thought that stuff was neat, and hope something similar
> > finds its way into the next Ada.
> 
> Signatures are being removed from the latest version of GNU C++.
> There is no need to "graft interface MI" into C++ because C++
> fully supports interface MI as it stands.

I disagree with your assertion. GNU C++ signatures allowed subtyping
*independent* of class hierarchy, and even allowed the extraction of 
a signature from an existing class using a "sigof" operator, something 
even Java doesn't have.

-- Brian

Re: friend classes in ada95

[Bill Greene]

Jeff Susanj wrote:
> 
> In OO a class is data and the operations associated with that data.
> Therefore, Ada doesn't explicitly have classes because the data and the
> operations are not explicitly bound together.  ...

This is the definition of an abstract data type.  Ada certainly does
support ADTs via the package mechanism.
-- 
William R. Greene                              1100 Perimeter Park Drive
Ganymede Software, Inc.                                        Suite 104
http://www.ganymede.com                       Morrisville, NC  27560 USA
Phone: (919) 469-0997, ext. 280                      Fax: (919) 469-5553

Re: MI, was Re: friend classes in ada95

[David Botton]

I want 1 and if I have 1 on Windows it would be nice if it did 2 so that I
could do COM.

I want 1 because I want 1, I already have COM with GNATCOM, I don't need 2,
but if I get 1 on Windows, it would be nice if it conformed to MSVC++/COM
style VTBLs.

I need to have some one reread my posts before sending for clarity, I still
don't see what is difficult about the above.

COM ain't Corba, COM as stated in my first ever COM announcement a year ago
is over glorified OO RPC.

What I am looking for is direct support of MI Interfaces in Ada, if I don't
get 2 then who cares.

David Botton


tmoran@bix.com wrote in message ...
>> What I am looking to do is introduce interface MI in to Ada syntax.
>> And if I am already going to implement it, I might as well do it in a
>> way that would make it easier to write a COM object in raw Ada.
>
>  I'm confused.  It seems you 1) want MI Interfaces; 2) want them in a
>binary compatible way (at least on Windows) with COM; 3) but
>"Inheritance and reusability are terms with specific meanins for the
>developer of object-oriented code.  These terms refer to the capability
>of deriving your own classes from the base classes, replacing methods
>with customized versions, and adding methods of your own.  None of this
>is available with respect to COM objects."  Visual C++ 5 Unleashed, p 510.

Re: friend classes in ada95

[Robert Dewar]

In article <38FCD19F.49DD6519@lmco.com>,
  John Rusnak <john.j.rusnak@lmco.com> wrote:
> Note that it is recommended in Ada as a matter of good style
> NOT to put more than one tagged type in a package.  (See
> Section9.6 of the Styl Guide).  And I have to agree with this
> design choice.  When I do have to put a seond tagged type in a
> package, I generally place it within the
> context of an internal (child?) package.


I find this seriously misguided advice, there is no reason
to treat tagged types specially here. Putting multiple related
types into a package often makes sense, whether or not they
are tagged.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert Dewar]

In article <38FD1830.949F5E81@mindspring.com>,
  "John J. Rusnak" <john.rusnak@mindspring.com> wrote:

> I'd have to weigh in on the opposite side.  "Class" and
> "object" are rather easy terms to grasp.

A tagged object in Ada is NOT a class in the OO sense, and oddly
this is true of a class in C++. Just because you call something
a class in C++ does not mean you are defining an object or class
in the OO sense.

I find that pretty confusing in C++ I must say, and it
definitely leads people into the realms of mega-confusion.
I often see people who define "classes" in C++ and thinking
they are doing object oriented programming, when they are just
defining abstract data types.

Class and object may be easy terms for you to grasp, but most
C++ programmers seem quite confused if you ask them to define
the difference between an abstract data type and an object.

Tagged types are simply types with particular properties that
are useful for many programming purposes (e.g. one use is to
simply ensure that objects (in the Ada sense!) of the type are
passed by reference, there are many many other uses, including
the fact that tagged types are suitable for representing
certain kinds of objects (in the OO sense).

> And I can tell you through exeperience that the Ada
> model has been difficult for many I have seen coming into the
> language to grasp.

Anyone who understands what types and abstract data types are
about should have no trouble with the Ada type model. If you are
talking about the "object" model of Ada, then my response is
that this is VERY confused thinking.

Object oriented programming is about a paradigm for program
design, it is not a language construct!

  (Some with OO backgrounds and some without).  But to each
their own
> I suppose.
>
> I agree with the comment on "code words", though.
>
> -John
>
> tmoran@bix.com wrote:
>
> > > A tagged type is not a class. A tagged type is a
programming construct
> >   When first trying to understand this stuff, I personally
found thinking
> > of a tag on a record etc to be much easier to understand
than all the
> > OO stuff about classes and objects.  "class" and "object"
are such
> > vague terms they convey little information. Also they are
used for
> > a variety of *different* things (see mathematics, or MS's
use of "class"
> > in COM).  OTOH, if one's intent is to certify membership in
an
> > exclusive club by the use of code words known only to the
members,
> > then "class" is as good as anything.
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert Dewar]

In article <38FD1C9E.7C2B7756@research.canon.com.au>,
  Geoff Bull <geoff@research.canon.com.au> wrote:
> For people coming from other languages, changing the word
> tagged to class is going to help not zero.

one too many negatives here??? :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert Dewar]

In article <xAbL4.310$up5.205418@news-east.usenetserver.com>,
  "David Botton" <David@Botton.com> wrote:

> The first step is getting them to come over from other
> languages and/or to think of Ada as even a possibility. The
> lack of the _code_word_ "class" is a huge wall, and since the
> introduction of Java, the lack of direct support
> for at least MI with interfaces is another.

Anyone for whom this is a "huge wall" is very poorly educated
about programming and programming languages -- yes I agree
this applies to lots of people, but I must say I have no
trouble introducing Ada notions to a large segment of graduate
students. That's at least one step of data above a completely
unsupported claim like the above.

I am completely unconvinced by the MI claim ... again it seems
quite unsubstantiated to me.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert Dewar]

In article <xAbL4.310$up5.205418@news-east.usenetserver.com>,
  "David Botton" <David@Botton.com> wrote:

> The first step is getting them to come over from other
> languages and/or to think of Ada as even a possibility. The
> lack of the _code_word_ "class" is a huge wall, and since the
> introduction of Java, the lack of direct support
> for at least MI with interfaces is another.

Anyone for whom this is a "huge wall" is very poorly educated
about programming and programming languages -- yes I agree
this applies to lots of people, but I must say I have no
trouble introducing Ada notions to a large segment of graduate
students. That's at least one step of data above a completely
unsupported claim like the above.

I am completely unconvinced by the MI claim ... again it seems
quite unsubstantiated to me.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert Dewar]

In article <Ft9rpt.4AF@news.boeing.com>,
  "Jeff Susanj" <jeffrey.l.susanj@boeing.com> wrote:
> In OO a class is data and the operations associated with that
> data.

This is a classical definition of an abstract data type, as
has been well understood since the early 60's.

If you really accept this as a definition of object, then that
seems very very confused to me!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert Dewar]

In article <uln2aq6oo.fsf@infomatch.com>,
  Ray Blaak <blaak@infomatch.com> wrote:
> I am realizing the saying obj.Method is a more natural way of
> expressing how I *think*.

but ONLY if Method is indeed an OO method, certainly I don't
think anyone prefers

Obj1."+" (Obj2)

  to

Obj1 + Obj2

The problem of people confusing tagged types with objects,
and primitive procedures with OO methods is a pretty severe
one, and adopting the prefix notation would most certainly
aggravate the situation.

It is conceivable that one might want to allow the prefix
alternative when wanted, but you certainly do NOT want to
insist on it in all cases.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert I. Eachus]

Robert Dewar wrote:
  
> Silly enough for you to have forgotten the issue :-) The issue
> was whether to treat underscores as letters in identifiers,
> removing the restrictions on the use of underscores. Actually
> the example most often used was a trailing underscore, but the
> general ability to mirror c identifiers such as a__b was also
> an issue.

   As near as I can remember, the four alternatives discussed were: no
change, allow trailing underscores, allow leading and trailing
underscores,
and treat underscore as if it was a letter.  Since no concensus
developed behind any change, the result was to stand pat.

   I personally think that the silliest part of this discussion ws on
allowing leading underscores, and I think that was what killed the most
general alternative.  But all that is detail. 
 
> > IMHO, the changed to the treatment of abstract made at a later
> > Boston meeting probably would not have been possible with the
> > syntax proposed by Jean Ichbiah.
> 
> That's plain wrong, or a misunderstanding, the notation
> 
>   class type x is record ...
> 
> as simply a syntactic transformation of
> 
>   type x is tagged record ...
> 
> is completely neutral with respect to such changes (indeed
> an Ada 95 compiler today could if it liked accept the first
> time as a source representation of the second form (though
> this kind of stretching of the notion of source representation
> is considered unsporting, even if allowed by the RM :-)

     The devil has always been in the details.  If the only difference
between Jean and Tucker's positions had been in the syntax, the online
discussions would not have been anywhere near as long.  In any case, the
particular feature that I was referring to was to have an abstract
formal private type and to derive another abstract type from it within
the generic specification, and finally derive a non-abstract type from
the instance:

    generic
      type Element is abstract tagged limited private;
    package Linked_Lists is
      type List_Element is abstract new Element with private;
      -- operations on lists...
    end Linked_Lists;

    ...

    package List_of_Strings is new      
Linked_Lists(Ada.Strings.Unbounded.Unbounded_String);

    type List_Element is new List_of_Strings.List_Element;

    This change made later, in Boston, required both syntax and semantic
changes, and I felt that it fit extremely well with the tagged type
grammar and semantics.  I do not feel that it would have fit nearly as
well with Jean's grammar, and would have required more semantic work. 
It was an extremely close call to even consider allowing the language
design team to even work on this, although the vote the next day to
adopt Tucker's proposal was overwhelming.  The amount of compiler change
was not an issue, but the amount of RM text to be changed was.  Since
this change was simplifying and unifying, it got in.  Would a similar
change to the class grammar have made it through?  I don't know.

Re: friend classes in ada95

[Jeff Carter]

Robert Dewar wrote:
> 
> In article <Ft9rpt.4AF@news.boeing.com>,
>   "Jeff Susanj" <jeffrey.l.susanj@boeing.com> wrote:
> > In OO a class is data and the operations associated with that
> > data.
> 
> This is a classical definition of an abstract data type, as
> has been well understood since the early 60's.
> 
> If you really accept this as a definition of object, then that
> seems very very confused to me!

Wirth, in accepting OO for Oberon, said that it's simply ADTs under
another name.

When I first looked into OO about 1984, once I finally understood what
was going on, I didn't find anything new, except that the mechanism used
made the code less readable than if composition had been used. I
suspected that the OO people made up new terms for well established
concepts such as type (class) and subprogram (methods) to mask this lack
of original content. I later learned that class came from Simula, but
have yet to learn any earlier use of method or message for subprogram or
call.

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail

Re: friend classes in ada95

[Ray Blaak]

Jeff Carter <jrcarter@acm.org> writes:
> Robert Dewar wrote:
> Wirth, in accepting OO for Oberon, said that it's simply ADTs under
> another name.
> 
> When I first looked into OO about 1984, once I finally understood what
> was going on, I didn't find anything new, except that the mechanism used
> made the code less readable than if composition had been used. I
> suspected that the OO people made up new terms for well established
> concepts such as type (class) and subprogram (methods) to mask this lack
> of original content.

OO programming being essentially about ADTs covers the most important and
worthwhile point. What makes OO programming different from ADTs, in least in my
opinion, is language support for inheritance and polymorphism.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: friend classes in ada95

[Geoff Bull]

"John J. Rusnak" wrote:
> 
> I'd have to weigh in on the opposite side.  "Class" and "object" are rather
> easy terms to grasp.   And I can tell you through exeperience that the Ada
> model has been difficult for many I have seen coming into the language to
> grasp.  (Some with OO backgrounds and some without).  But to each their own
> I suppose.
> 
For people coming from other languages, changing the word tagged to class
is going to help not zero.
The problem they face is overcoming the assumptions they have made 
about how oo is implemented.

Re: friend classes in ada95

[Jean-Pierre Rosen]

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


John J. Rusnak <john.rusnak@mindspring.com> a �crit dans le message :
38FD1830.949F5E81@mindspring.com...
> I'd have to weigh in on the opposite side.  "Class" and "object" are
rather
> easy terms to grasp.   And I can tell you through exeperience that the Ada
> model has been difficult for many I have seen coming into the language to
> grasp.  (Some with OO backgrounds and some without).  But to each their
own
> I suppose.
>
I beg to differ. My experience is that Ada'OO model is quite easy to
understand (and FYI, training in Ada is my primary business). Especially,
dispatching is easier to explain than in other language:

"If something is of a class wide type, the actual type is not known at
compile time; therefore, overloading resolution is done at execution time,
when the type is known".

I have seen people who never quite understood dispatching in C++ that easily
understood this explanation.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: friend classes in ada95

[Ehud Lamm]

My experience (I guess every teacher has his own views) is that many of
those finding Ada OO model difficult simply don't really understand ANY OO
model. They understand the "surface structure" (i.e., the syntax) which is
naturally different between languages. A minority who is well versed in
some other language (C++/Java) can have problems with the the Ada way of
doing things, but usually can overcome this pretty easily.

I also tend to agree that people seem to understand the Ada way of doing
things faster, but than I haven't taught C++ recently - so maybe if *I*
teach C++ it will understood better and faster too.

Lastly, I think that it is helpful to know that there is more than one way
to skin a cat (not to mention that there are so many cats), so being
exposed to a language like Ada, with its own unique ways, should be seen
as a bonus, not as a problem.
obstacle. 

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: friend classes in ada95 (long)

[Hyman Rosen]

Brian Rogoff <bpr@shell5.ba.best.com> writes:
> There was some work at grafting interface MI into C++, indeed I believe
> that GNU C++ may still support the "signature" proposal of Russo and 
> Baumgartner. I thought that stuff was neat, and hope something similar
> finds its way into the next Ada.

Signatures are being removed from the latest version of GNU C++.
There is no need to "graft interface MI" into C++ because C++
fully supports interface MI as it stands.

Re: friend classes in ada95

[Robert Dewar]

In article <8dmj62$4i7$1@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> i.e. that a program is
> no more defined as a sequence of actions to be performed by a
> computer, but as a representation, a modelization, of the real
> world. FWIW.

No, that's much too broad, the object oriented approach is
only one particular way of representing or modeling the
world.

COBOL programs have traditionally modeled the accounting
world for example, pretty literally, but often in ways that
are purely procedural (the real world does contain procedures
as well as objects :-)

Indeed this points out the ultimate weakness of relying on the
OO paradign for everything.

Obviously you can do any computing task using any computation
approach, we all know that.

Therefore, Q.E.D. you can do anything using an object oriented
approach, so we all know that too, and it proves nothing.

The point is that the OO approach is most often useful ONLY
if it does indeed model the real world, so if your real world
problem is not naturally "object oriented", then forcing it
into the OO paradigm may considerably distort the model.

The fact that there are those around (some in this thread) who
think OO is all about ADT features in languages further confuses
the issue, and results in a lot of confused code!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Geoff Bull]

Robert Dewar wrote:
> I am completely unconvinced by the MI claim 
Me too - first you have to get 'em to the stage where they
might even notice there is no MI.

Also, Java would be a sorry language without interfaces, but with
Ada there is usually another (often better) way, e.g. generics.

Re: friend classes in ada95

[BSCrawford]

Robert, you said

>No, that's much too broad, the object oriented approach is
>only one particular way of representing or modeling the
>world.

You have pointed out that several commonr notions of what the 
object oriented approach is are wrong.  Could you please give 
us a brief characterization of what it is?  For example, how is 
it different from an approach based on ADT's classified using 
inheritance hierarchies? 

Bard Crawford

Re: friend classes in ada95

[Ray Blaak]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:
> I would rather say that what makes OO is the fact that ADT's represent and
> are modelled after real-life objects, i.e. that a program is no more defined
> as a sequence of actions to be performed by a computer, but as a
> representation, a modelization, of the real world. FWIW.

I have always disagreed with this. After all, you can use the OO paradigm to
model abstract concepts that don't exist in the real world. That real-world
objects are often most easily modelled using the OO paradigm is instead a
matter of a good application of OO, as opposed to a definition of OO.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: friend classes in ada95

[Brian Rogoff]

On Thu, 20 Apr 2000, Robert Dewar wrote:
> In article <8dmj62$4i7$1@wanadoo.fr>,
>   "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> > i.e. that a program is
> > no more defined as a sequence of actions to be performed by a
> > computer, but as a representation, a modelization, of the real
> > world. FWIW.
> 
> No, that's much too broad, the object oriented approach is
> only one particular way of representing or modeling the
> world.
> 
> COBOL programs have traditionally modeled the accounting
> world for example, pretty literally, but often in ways that
> are purely procedural (the real world does contain procedures
> as well as objects :-)
> 
> Indeed this points out the ultimate weakness of relying on the
> OO paradign for everything.
> 
> Obviously you can do any computing task using any computation
> approach, we all know that.
> 
> Therefore, Q.E.D. you can do anything using an object oriented
> approach, so we all know that too, and it proves nothing.
> 
> The point is that the OO approach is most often useful ONLY
> if it does indeed model the real world, so if your real world
> problem is not naturally "object oriented", then forcing it
> into the OO paradigm may considerably distort the model.

I would have guessed that you are American, not Scandinavian :-)

For those who don't get the reference, the Scandinavians, that is, the 
designers of Simula and BETA, refer to two different views of OO which
they call the "Scandinavian" and "American" views, where the Scandinavian 
view is concerned with "real world" (whatever that is) modeling and the 
American with using OO as a software engineering tool concerned with 
the structure of the source code. This is an oversimplification of course,
if you want the full story read one of the books by Madsen on the topic,
like the BETA book.

Since I have no idea what this "real world" is and how it helps me write
code, I'm pretty much an American. 

I'm certainly looking forward to reading Robert's contrary views on OOP. 
I suspect that we won't be able to get a hard and fast definition of OOP 
or OOPL that everyone agrees on.

-- Brian

Re: friend classes in ada95

[Ray Blaak]

Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <m3hfcxjt22.fsf@ns58.infomatch.bc.ca>,
>   Ray Blaak <blaak@infomatch.com> wrote:
> > OO programming being essentially about ADTs covers the most
> > important and worthwhile point. What makes OO programming
> > different from ADTs, in least in my opinion, is language
> > support for inheritance and polymorphism.
> 
> nope! that has nothing to do with object oriented programming.

Well, "nothing to do" is a little strong. All of the OO languages give exactly
these features, and saying a language is an "Object-Oriented" language has
some meaning precisely because of this fact.

> Example. Suppose we define an abstract algebra as a tagged
> type. The operations are purely value oriented (e.g. operation
> + on two elements computes a third element).

I am perfectly comfortable with calling this OO.

> What does not make sense is to think of this as object
> oriented programming, since the two fundamental components
> of objects:
> 
>   1. state, so that objects can be changed

Are you saying that only mutable things can be considered as objects? That
seems extreme to me. 

>   2. methods with message passing semantics so that the
>      operations are viewed as passing a message to the
>      distinguished object (the prefix in languages that
>      use this syntax)

I think I agree with this one (that it is fundamental to OO), although I point
out that there does not have to be a single distinguished object (e.g. Common
Lisp's object system works in general with multiple distinguished
objects). The important thing is the conceptualization of the problem into a
collection of entities that are responsible for doing things to themselves and
each other.

> are completely missing.

I would assert that your example actually has both of the
characteristics. With regards to state, even if there is no specifically
modelled state, one still has object identity in relation to other objects
(e.g. A+B is (often) different from both A and B). With regards to message
semantics, the "+" operator would presumably be implemented by doing some sort
of evaluation of its arguments, "asking" them questions about themselves ("who
are you?" at the very least).

> If you think that OO is simply about ADT's then you are back
> in the 60's and have missed something :-)
> 
> On the other hand, if you think that type extension, information
> hiding, and dynamic dispatching are ONLY about object oriented
> programming, then you have also missed something!

It's a matter of semantics. "Object-Oriented" as a term tends to be fairly
vague, which is why we have threads like this. I like programming by
conceptualizing the problem in terms of "objects", and using type extension,
information hiding and dynamic dispatching. I don't necessarily use all of
these features simultaneously. I call it OO anyway. I don't think I am alone,
but I am not that worried about it.

The important thing for me is to make robust, well-designed and maintainable
software. OO as a term is really only important to me during job interviews.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: friend classes in ada95

[Ray Blaak]

Robert Dewar <robert_dewar@my-deja.com> writes:
> This is a completely incorrect memory, there was no close call.
> Just look at the minutes!

Are any of these minutes available online? I seem to recall some things about
the Ada 9X design process being available, but can't seem to find anything
now. Did it used to be at AJPO? Are there any AJPO archives anywhere? (There
seems to have been a concerted effort to "disappear" all online AJPO
materials, including mirrors).

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: friend classes in ada95

[Charles Hixson]

My original definition of an Object (I was coming to C++ from C after being
exposed to Apple's Object Pascal) was:
An object is a data structure combined with the methods defined to access it.  It
is made useful by inheritance.
I still think that this is the "basic" definition in most languages, however Ada
and Lisp parse the world very differently.  In their view, the methods are NOT a
part of the object.  So we are left with Tagged ADT's which are made useful
through inheritance.  Personally, I think that it makes a reasonable amount of
sense to chunk the methods with the object, but I'm not vehement on the point, and
I'm still very new to Ada, so perhaps my opinion will change.
However, in Ada an object appears to be a tagged abstract data type.  This is a
language dependent definition, but ANY workable definition of a computer language
object WILL BE language dependent.  (Or so it seems to me.)

Re: friend classes in ada95

[Jeff Carter]

Robert Dewar wrote:
> > I suspected that the OO people made up new terms for well
> > establishe concepts such as type (class) and subprogram
> > (methods) to mask this lack of original content.
> 
> Then you are missing something too.

That's certainly possible, but so far no one has been able to show me
what.

It's also important to differentiate between the two common meanings of
OO. One means "object oriented", as in OOD. The other means "implemented
using inheritance and dispatching", as in OOP. Obviously, there is
nothing inherently object oriented about the latter, and I have seen
plenty of "OO" code that had nothing object oriented about it.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: friend classes in ada95

[Robert Dewar]

In article <38FE365D.31C893A6@acm.org>,
  jrcarter@acm.org wrote:

> Wirth, in accepting OO for Oberon, said that it's simply ADTs
> under another name.

If that's accurately stated, he is missing something!

> When I first looked into OO about 1984, once I finally
> understood what was going on, I didn't find anything new,
> except that the mechanism use made the code less readable than
> if composition had been used.

Well seeing as it is Simula-*67* you would hardly expect to
find anything new in 1984!

> I suspected that the OO people made up new terms for well
> establishe concepts such as type (class) and subprogram
> (methods) to mask this lack of original content.

Then you are missing something too.

The object oriented programming paradigm, involving objects
with state, with a message passing discipline between objects,
is a valuable one with many applications (although trying to
bend it to all applications is unfortunate).

I know these two positions well:

   All abstract data types are objects, and anything I do with
   ADT's is OO programming.

   There is no such thing as OO, it's all hype.

But neither of these is a helpful illuminating position!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert Dewar]

In article <38FE442C.92F7C2B3@earthlink.net>,
  "Robert I. Eachus" <rieachus@earthlink.net> wrote:
>
> As near as I can remember, the four alternatives discussed
> were: no change, allow trailing underscores, allow leading and
> trailing underscores and treat underscore as if it was a
> letter.  Since no concensus
> developed behind any change, the result was to stand pat.

Again, your memory is flawed here, you should check the minutes
of the Salem meeting. In particular, the rejection was nothing
to do with lack of consensus behind any one scheme, but rather
to do with dislike for the whole idea. In particular you should
be able to recall the fierce opposition of the French delegation
on this point :-)

> I personally think that the silliest part of this discussion
> was on allowing leading underscores, and I think that was what
> killed the most general alternative.  But all that is detail.

Yes, and incorrect detail at that, this was not at ALL the
dynamics of the discussion. In particular, perhaps you can
recall the strong point that was made that with modern
variable width type fonts, it is hard to tell how many
underscores are in a sequence of underscores ... that was
the primary French objection to the motion.
>
>
>  I do not feel that it would have fit nearly as
> well with Jean's grammar, and would have required more
semantic work.

I disagree

> It was an extremely close call to even consider allowing the
language
> design team to even work on this,

This is a completely incorrect memory, there was no close call.
Just look at the minutes!



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert Dewar]

In article <m3hfcxjt22.fsf@ns58.infomatch.bc.ca>,
  Ray Blaak <blaak@infomatch.com> wrote:

> OO programming being essentially about ADTs covers the most
> important and worthwhile point. What makes OO programming
> different from ADTs, in least in my opinion, is language
> support for inheritance and polymorphism.

nope! that has nothing to do with object oriented programming.
inheritance and polymorphism are concepts that perfectly well
fit into the general world of ADT's.

Example. Suppose we define an abstract algebra as a tagged
type. The operations are purely value oriented (e.g. operation
+ on two elements computes a third element).



The notion of extending the abstract algebra to a concrete
field makes perfect sense, and the notion of dynamic dispatching
to allow routines to deal with different algebras also makes
sense.

What does not make sense is to think of this as object
oriented programming, since the two fundamental components
of objects:

  1. state, so that objects can be changed

  2. methods with message passing semantics so that the
     operations are viewed as passing a message to the
     distinguished object (the prefix in languages that
     use this syntax)

are completely missing.

When Simula-67 was introduced, ADT's were of course very well
known and understood (this was after all a decade after Algol-60
was introduced!) Simula-67 had something original and
interesting to add to the programmer's knowledge base.

If you think that OO is simply about ADT's then you are back
in the 60's and have missed something :-)

On the other hand, if you think that type extension, information
hiding, and dynamic dispatching are ONLY about object oriented
programming, then you have also missed something!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Jean-Pierre Rosen]

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


Ray Blaak <blaak@infomatch.com> a �crit dans le message :
m3hfcxjt22.fsf@ns58.infomatch.bc.ca...
> OO programming being essentially about ADTs covers the most important and
> worthwhile point. What makes OO programming different from ADTs, in least
in my
> opinion, is language support for inheritance and polymorphism.

Certainly not. What you describe is classification, which is one way of
organizing objects. Composition is another one, and there might be others to
be invented. I would rather say that what makes OO is the fact that ADT's
represent and are modelled after real-life objects, i.e. that a program is
no more defined as a sequence of actions to be performed by a computer, but
as a representation, a modelization, of the real world. FWIW.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: friend classes in ada95

[Jean-Pierre Rosen]

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


Robert Dewar <robert_dewar@my-deja.com> a �crit dans le message :
8dmm12$1j7$1@nnrp1.deja.com...
> The point is that the OO approach is most often useful ONLY
> if it does indeed model the real world, so if your real world
> problem is not naturally "object oriented", then forcing it
> into the OO paradigm may considerably distort the model.
>
Absolutely. I have a book about Eiffel that takes as a first example of
OOP... an expression evaluator.
Every time you encounter a (sub)expression, you create an "expression"
object, call its "evaluate" method, and then destroy the object...

Like M. Gauthier likes to say: "not everything is an object"

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: friend classes in ada95

[Jean-Pierre Rosen]

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


Ray Blaak <blaak@infomatch.com> a �crit dans le message :
ug0sg4vmk.fsf@infomatch.com...
> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:
> > I would rather say that what makes OO is the fact that ADT's represent
and
> > are modelled after real-life objects, i.e. that a program is no more
defined
> > as a sequence of actions to be performed by a computer, but as a
> > representation, a modelization, of the real world. FWIW.
>
> I have always disagreed with this. After all, you can use the OO paradigm
to
> model abstract concepts that don't exist in the real world. That
real-world
> objects are often most easily modelled using the OO paradigm is instead a
> matter of a good application of OO, as opposed to a definition of OO.
>
By "real world", I mean things that normal people (i.e. not computer
wizzards) can deal with; of course it includes abstract concepts. What I
mean is that you think in terms of "catalog of goods", not in terms of
"hash-table of unique references in the data base".

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: friend classes in ada95

[Jon S Anthony]

Charles Hixson wrote:

> My original definition of an Object (I was coming to C++ from C
> after being exposed to Apple's Object Pascal) was: An object is a
> data structure combined with the methods defined to access it.  It
> is made useful by inheritance.

Or true delegation (you don't need to have class based "oo" to have
"oo", ;-)


> I still think that this is the "basic" definition in most languages,
> however Ada and Lisp parse the world very differently.  In their
> view, the methods are NOT a part of the object.

They are just being more "honest" - the methods are not part of the
object in nearly any of these other languages either.  About the only
exceptions to this are some CL based methods-per-object object systems
and Object Logo.

Note that building a standard simple "distinguished object" version of
OO in CL is about 4 or 5 pages of code.  Complete with standard
module/class conflation, er constructs, method definition, etc.  Even
includes MI.


>  So we are left with Tagged ADT's which are made useful

In Ada.

In CLOS you have: generic functions and true multiple dispatch (+ the
MOP, with which you can decide your own method dispatch protocol if
need be).


> through inheritance.  Personally, I think that it makes a reasonable
> amount of sense to chunk the methods with the object, but I'm not
> vehement on the point,

It is the naive and simplistic way.  It is also rather limited (and
limiting) and a poor way if you really are interested in creating
highly expressive systems, i.e., solving problems and not just
interested in towing the standard simplistic OO line.

Frankly, the standard OO line is highly overrated and rather boring.


/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: friend classes in ada95

[Jon S Anthony]

Robert Dewar wrote:
> 
> In article <38FF804E.BB59D751@acm.org>,
>   jrcarter@acm.org wrote:
> > and I have seen
> > plenty of "OO" code that had nothing object oriented about it.
> 
> OO *means* object oriented, so the above is a contradiction
> in terms. To describe code that has nothing object oriented
> about it as OO is simply wrong.

You missed the scare-quotes around "OO" (here the quotes are _not_
scare quotes!)


/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: friend classes in ada95

[Robert Dewar]

In article <38FF804E.BB59D751@acm.org>,
  jrcarter@acm.org wrote:
> and I have seen
> plenty of "OO" code that had nothing object oriented about it.


OO *means* object oriented, so the above is a contradiction
in terms. To describe code that has nothing object oriented
about it as OO is simply wrong.

Yes, a lot of people are confused, but what else is new? Most
of the people writing C++ today are very seriously confused
about a lot of things!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Ken Garlington]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:8dq859$sae$1@nnrp1.deja.com...
> In article <38FF804E.BB59D751@acm.org>,
>   jrcarter@acm.org wrote:
> > and I have seen
> > plenty of "OO" code that had nothing object oriented about it.
>
>
> OO *means* object oriented, so the above is a contradiction
> in terms.

But does "OO" (vs. OO) mean object oriented? (e.g., the Mafia "persuaded"
the witness to not testify.)

Re: friend classes in ada95

[Jean-Pierre Rosen]

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


Charles Hixson <charleshixsn@earthlink.net> a �crit dans le message :
38FF3914.839040E2@earthlink.net...
>
> My original definition of an Object (I was coming to C++ from C after
being
> exposed to Apple's Object Pascal) was:
> An object is a data structure combined with the methods defined to access
it.  It
> is made useful by inheritance.
This seems to imply that an object is not "useful" unless you use
inheritance.
I'd like some evidence to support that claim (the fact that many gurus do it
is not supporting evidence to me).

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: friend classes in ada95

[Robert Dewar]

In article <3900FFF9.51C9@synquiry.com>,
  Jon S Anthony <jsa@synquiry.com> wrote:

> You missed the scare-quotes around "OO" (here the quotes are
> _not_ scare quotes!)

Ah, I got it! As in C++ is an "OO" language :-)

or "look at me, I used // for comments so this is an "OO"
program :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: friend classes in ada95

[Robert I. Eachus]

Robert Dewar wrote:
  
> Again, your memory is flawed here, you should check the minutes
> of the Salem meeting. In particular, the rejection was nothing
> to do with lack of consensus behind any one scheme, but rather
> to do with dislike for the whole idea. In particular you should
> be able to recall the fierce opposition of the French delegation
> on this point :-)

    My memory of the discussion was that the debate was mostly between
leading, leading and trailing, and underscore as a letter, rather than
between those who favored some change and those in favor of no change. 
Of course, I might have missed some of the debate running various
errands, but I think I was there for most if not all of it.  In any
case, I think that the some people voted against change since there was
no strong consenus in favor of a single proposal.  I don't think I can
verify or falsify that from the minutes. 
> 
> > I personally think that the silliest part of this discussion
> > was on allowing leading underscores, and I think that was what
> > killed the most general alternative.  But all that is detail.
> 
> Yes, and incorrect detail at that, this was not at ALL the
> dynamics of the discussion. In particular, perhaps you can
> recall the strong point that was made that with modern
> variable width type fonts, it is hard to tell how many
> underscores are in a sequence of underscores ... that was
> the primary French objection to the motion.

   I didn't say it was all of the discussion, just the silliest part.
Some delegates actually thought it was important for interfacing to C,
while many
who actually wrote interfaces to C found the idea of such names
contaminating their code distasteful.  As a result we had a lot of
people talking past each other--one group feeling it was necessary for
functionality and the other--including the French, opposed on style
grounds. 
 
> > It was an extremely close call to even consider allowing the
> > language design team to even work on this,

> This is a completely incorrect memory, there was no close call.
> Just look at the minutes!

    And what will I find?  There was a discussion of whether or not it
was too late to consider changes to the grammar.  However, since the
existing grammar was obviously broken, I don't think that there was even
a vote on that.  Then there was a discussion of whether to require the
design team to make the smallest possible change.  Tucker strongly
argued that he thought that the total (text) change for the more
radical--and elegant--fix was small, and offered to work on it
overnight.  He did, and it was small, but I think that, with time to
sleep on it, everyone who understood the issue was in favor, even if it
had turned out to be a large change.   So, as I recall, there was a
close call on whether or not it was too late for a change of this
mangitude, but once a full proposal was put on the table, no one was
against it.  (In fact the only subject of any discussion at all was the
order of keywords, resolving to "type Foo is abstract tagged limited
private;"

Re: friend classes in ada95 (long)

[Brian Rogoff]

On 23 Apr 2000, Hyman Rosen wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > > Signatures are being removed from the latest version of GNU C++.
> > > There is no need to "graft interface MI" into C++ because C++
> > > fully supports interface MI as it stands.
> > 
> > I disagree with your assertion. GNU C++ signatures allowed subtyping
> > *independent* of class hierarchy, and even allowed the extraction of 
> > a signature from an existing class using a "sigof" operator, something 
> > even Java doesn't have.
> 
> Which assertion? Signatures are definitely being removed from GNU C++.
> This has been proclaimed on the official mailing lists by official
> maintainers. 

Obviously not that one. 

> As to the other, the message to which I responded was talking
> about Java, so I meant that C++ has interface MI which is the equal of
> Java (nearly, with an exception I've posted before). 

The assertion that C++ fully suports MI of interface. Since you were 
responding to my message about GNU C++ signatures, I foolishly assumed 
that you were talking about GNU C++ signatures, not Java. Silly me!

> It certainly needs no "grafting".

It seems that I ruffled your feathers by using that word in the context of 
your favorite language. Sorry. I actually liked the signature extension of 
C++. I'd love to see such a feature grafted onto Ada.

-- Brian

Re: friend classes in ada95 (long)

[Hyman Rosen]

Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > Signatures are being removed from the latest version of GNU C++.
> > There is no need to "graft interface MI" into C++ because C++
> > fully supports interface MI as it stands.
> 
> I disagree with your assertion. GNU C++ signatures allowed subtyping
> *independent* of class hierarchy, and even allowed the extraction of 
> a signature from an existing class using a "sigof" operator, something 
> even Java doesn't have.

Which assertion? Signatures are definitely being removed from GNU C++.
This has been proclaimed on the official mailing lists by official
maintainers. As to the other, the message to which I responded was talking
about Java, so I meant that C++ has interface MI which is the equal of
Java (nearly, with an exception I've posted before). It certainly needs
no "grafting".

Re: friend classes in ada95

[Ray Blaak]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:
> By "real world", I mean things that normal people (i.e. not computer
> wizzards) can deal with; of course it includes abstract concepts. What I
> mean is that you think in terms of "catalog of goods", not in terms of
> "hash-table of unique references in the data base".

Ok, fair enough. I would instead say "think in terms of entities of the
problem domain", however. One can implement the catalog of goods using a
hash-table, but for the implementor of the hash-table service, the problem
domain becomes indeed "wizard" concepts. 

I don't see any reason why a certain class of abstractions (i.e. programming
ones) is not appropriate for OO conceptualization just like any other. The
real point is to use the appropriate abstractions for the domain.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: friend classes in ada95 (long)

[Hyman Rosen]

Brian Rogoff <bpr@shell5.ba.best.com> writes:
> It seems that I ruffled your feathers by using that word in the context of 
> your favorite language. Sorry. I actually liked the signature extension of 
> C++. I'd love to see such a feature grafted onto Ada.

Sorry about that. My antennae sometimes get a little hyperextended in
c.l.a. But as to signatures, I don't much care for them. It seems to
me that they are there to take advantage of accidents in function
naming, whereas interfaces are part of a design.

Re: friend classes in ada95 (long)

[Brian Rogoff]

On 24 Apr 2000, Hyman Rosen wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > It seems that I ruffled your feathers by using that word in the context of 
> > your favorite language. Sorry. I actually liked the signature extension of 
> > C++. I'd love to see such a feature grafted onto Ada.
> 
> Sorry about that. My antennae sometimes get a little hyperextended in
> c.l.a. 

You'll probably have to develop a thicker skin, or tougher antennae,  
because this is com.lang.ada after all. I'm similarly annoyed by the 
gratuitous C++ slamming, even though I prefer Ada to C++ for most tasks, 
but that's the nature of comp.lang.*

> But as to signatures, I don't much care for them. It seems to
> me that they are there to take advantage of accidents in function
> naming, whereas interfaces are part of a design.

Is that from actual use, or just reading and inference? I don't have any 
real data myself, I just read about GNU C++ signatures. I did use Sather 
for a while, which also had a powerful signature-like mechanism that 
permitted the addition of signatures (types in Sather parlance) above 
an existing class. This feature was mainly used to define type bounds in 
generic classes. Since C++ doesn't have constrained parametric
polymorphism (yes, I know how to simulate it inelegantly in C++) this
isn't as important there. 

The real revolutionary aspect of standard C++ which I wish Ada would copy
is automatic generic/template instantiation. I think the modification to
Ada (read "An Ada like language") would be better off omitting the full
power of templates to do compile time calculations, and therefore omitting 
"template metaprogramming", but would still enhance Ada's abilities in a 
number of interesting ways. 

-- Brian

Re: friend classes in ada95 (long)

[Ole-Hjalmar Kristensen]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> On 24 Apr 2000, Hyman Rosen wrote:
> > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > > It seems that I ruffled your feathers by using that word in the context of 
> > > your favorite language. Sorry. I actually liked the signature extension of 
> > > C++. I'd love to see such a feature grafted onto Ada.
> > 
> > Sorry about that. My antennae sometimes get a little hyperextended in
> > c.l.a. 
> 
> You'll probably have to develop a thicker skin, or tougher antennae,  
> because this is com.lang.ada after all. I'm similarly annoyed by the 
> gratuitous C++ slamming, even though I prefer Ada to C++ for most tasks, 
> but that's the nature of comp.lang.*
> 
> > But as to signatures, I don't much care for them. It seems to
> > me that they are there to take advantage of accidents in function
> > naming, whereas interfaces are part of a design.
> 
> Is that from actual use, or just reading and inference? I don't have any 
> real data myself, I just read about GNU C++ signatures. I did use Sather 
> for a while, which also had a powerful signature-like mechanism that 
> permitted the addition of signatures (types in Sather parlance) above 
> an existing class. This feature was mainly used to define type bounds in 
> generic classes. Since C++ doesn't have constrained parametric
> polymorphism (yes, I know how to simulate it inelegantly in C++) this
> isn't as important there. 
> 
> The real revolutionary aspect of standard C++ which I wish Ada would copy
> is automatic generic/template instantiation. I think the modification to
> Ada (read "An Ada like language") would be better off omitting the full
> power of templates to do compile time calculations, and therefore omitting 
> "template metaprogramming", but would still enhance Ada's abilities in a 
> number of interesting ways. 
> 
> -- Brian
> 
> 

Yes, I think it's sensible to restrict the power of templates, at
least from an implementation view. I've seen so many C++ compilers
that either fail to compile, or generate wrong code for complex
templates. I still feel I cannot really trust C++ templates.

-- 
E pluribus Unix

Re: friend classes in ada95

[Aidan Skinner]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

> This seems to imply that an object is not "useful" unless you use
> inheritance.
> I'd like some evidence to support that claim (the fact that many gurus do it
> is not supporting evidence to me).

I'd tend to think that an object *shouldn't* be useful unless it's a
descendent of a more abstract one. I like to have a base class which
is abstract and then inherit from that, even if I've only got one
descendant at the time and I don't forsee the need for any more. It
saves having to rework stuff later.

- Aidan
-- 
http://www.reality.co.uk/
http://www.skinner.demon.co.uk/aidan/
"I could always suspend a few hundred accounts and watch what happens"

Re: friend classes in ada95

[Robert I. Eachus]

Aidan Skinner wrote:
 
> I'd tend to think that an object *shouldn't* be useful unless it's a
> descendent of a more abstract one. I like to have a base class which
> is abstract and then inherit from that, even if I've only got one
> descendant at the time and I don't forsee the need for any more. It
> saves having to rework stuff later.

    Hmmm...  I like to say that Ada class hierarchies are bushier.  It
seems to turn out that if you take, say a Smalltalk class hierarchy and
re-implement it in Ada, you end up with a forest instead of a single
tree (no surprise), and most of the public derivation trees have either
a single entry or a root and a number of child classes.  In the private
(implementation) part of the hierarchy there may be intermediate
classes, but unless you are extensively using generic mix-ins, the trees
are still short and fat.

    (And yes I am working on a paper on this right now.  And the funny
thing is, it ends up recommending mix-ins all over the implementation
space.  But the public model is stays sparse, and does not make much use
of multi-level inheritance.)