Sugestion to Multiple Inheritance

Sugestion to Multiple Inheritance

[Lutz Donnerhacke]

I'm looking for a design glue to build something like this:

 I have an several (at least two) interfaces with must be implemented
 by the end user (compiler should require implementation). All of them
 build a free(!) depedency tree. The simplest one is:
    
     A -> B     B is an extended A and C is an extended A.
     |    |     D combines both extensions (requiring both).
     v    v
     C -> D
 
 There are (generic) packages requiring special interfaces.

I'd like to use abstract types and class wide programming, but this can't be
done in Ada naturally.

The rationale suggests three solutions in chapter "4.6  Multiple Inheritance":
  - Adding B as a component extension of C to form D.
    This is not possible for abstract types.
  - Mixin Inheritance
    The extensions for B can be implemented as a mixin, but this results in
    diffenent instantions for B and D. So D can not be converted to B.
  - Adding B with access to D as a component extension of C to form D.
    This is not possible for abstract types.

Combining those: 
  - Adding B as a access constraint of C to form D.
    Its possible to define "type D (b_view : access B) is new C;"
    But this requires double instantiation of the complex data structure of A
    and double maintainces of this data structure. So it's error prone.
    It's even not possible to drop D into a B'Class argument, requiring
    multiple implementations of the same algorithm.

In order to overcome the multiple implementations constraint, it's possible
to generalize more and building the using package generic in the A -> C
abstract type and the used mixin for the B functionality.

Better solutions?

Re: Sugestion to Multiple Inheritance

[Stephen Leake]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> I'm looking for a design glue to build something like this:
> 
>  I have an several (at least two) interfaces with must be implemented
>  by the end user (compiler should require implementation). All of them
>  build a free(!) depedency tree. The simplest one is:
>     
>      A -> B     B is an extended A and C is an extended A.
>      |    |     D combines both extensions (requiring both).
>      v    v
>      C -> D
>  
>  There are (generic) packages requiring special interfaces.

I need more information about why C and B need to be independent
types. Perhaps you can just do:

A -> BC -> D 

Basically, you've drawn a diagram that can't be implmented in Ada, and
asked how to implement it. The only solution is to give more
information about the real problem, so we can suggest how to modify
the diagram so it can be implemented.

-- 
-- Stephe

Re: Sugestion to Multiple Inheritance

[Lutz Donnerhacke]

* Stephen Leake wrote:
>lutz@iks-jena.de (Lutz Donnerhacke) writes:
>>      A -> B     B is an extended A and C is an extended A.
>>      |    |     D combines both extensions (requiring both).
>>      v    v
>>      C -> D
>
>I need more information about why C and B need to be independent types.

They do not need to be types at all. They are abstactions => interfaces.
Example: A describes a sort algorithm. B describes stableness. C describes
in-place-ness. D describes stable, in-place sort algorithms.

The problem becomes worse if more attributes are required.

Planned usage:

   generic
      ....  Stable_Sort ...;
   package
      ...
   end package;

If I define a implementation of D, I'd like to use is in contexts where A,
B, or C is required as well.

>Basically, you've drawn a diagram that can't be implmented in Ada, and
>asked how to implement it.

Ack. And I offered some solutions. I won't complain about a missing feature.

>The only solution is to give more information about the real problem, so
>we can suggest how to modify the diagram so it can be implemented.

HTH.

Re: Sugestion to Multiple Inheritance

[Mark Lundquist]

Can you try again, this time with more detail?  I can't tell which types you
want to be abstract, what things are generic and what that has to do with
the problem, what things your user is required to implement, etc.

Maybe some cut-down code examples would help...

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrna3tf3u.kg.lutz@taranis.iks-jena.de...
> I'm looking for a design glue to build something like this:
> [snip...]
>
>   - Adding B with access to D as a component extension of C to form D.
>     This is not possible for abstract types.

Would it help to make your access discriminant an access-to-classwide-type?

-- mark

Re: Sugestion to Multiple Inheritance

[Richard Riehle]

Lutz Donnerhacke wrote:

> The rationale suggests three solutions in chapter "4.6  Multiple Inheritance":

None of those suggestions in the Rationale satisfies the requirements
for multiple inheritance.  They are simply workarounds.   There is
no MI in Ada, period.   That is not a bad thing, but it is a fact.

MI, as with any inheritance, requires satisfying the Liskov Substitutatility
Priniciple.  None of the workarounds do.    MI implies a corresponding
available of polymorphic types. None of the workarounds do.    MI
implies dispatching, dynamically,  on any derivation of a type in the
inheritance hierarchy.  None of the workarounds do.

In my view, MI is still a research topic.  There is no universally accepted
model, and no foolproof design, at this stage, in any language, that can be
said to solve all the problems.   Eiffel may come the closest to getting it
right, but even with Eiffel,  any discussion of MI requires a long and
detailed understanding of repeated inheritance and other entertaining
issues.    With C++, MI is probably a disaster waiting to happen.

Why would anyone want MI.  MI is most useful if you have a need for
polymorphic dispatching types. Grady Booch suggests that when you need
MI, you really need it.      The frequency with which one needs MI,
contrasted with the risks associated with it should make one pause
before deciding that it should be included in a language design
where software safety is an issue.    Tucker go this one right.

Richard Riehle

Re: Sugestion to Multiple Inheritance

[Stephen Leake]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> * Stephen Leake wrote:
> >lutz@iks-jena.de (Lutz Donnerhacke) writes:
> >>      A -> B     B is an extended A and C is an extended A.
> >>      |    |     D combines both extensions (requiring both).
> >>      v    v
> >>      C -> D
> >
> >I need more information about why C and B need to be independent types.
> 
> They do not need to be types at all. They are abstactions => interfaces.
> Example: A describes a sort algorithm. B describes stableness. C describes
> in-place-ness. D describes stable, in-place sort algorithms.

Well, if they don't have to be types, you can easily do it in Ada. But
all your complaints were that it could not be done with abstract Ada
types. 

-- 
-- Stephe

Re: Sugestion to Multiple Inheritance

[Hyman Rosen]

Richard Riehle wrote:
 > With C++, MI is probably a disaster waiting to happen.

Uh, oh. Drive-by shooting alert!
Do you care to back up that statement with facts?

Hint: search for the C++ ABI document which is now being
used in implementing gcc. It's not a disaster, but it's
*very* complicated.

Re: Sugestion to Multiple Inheritance

[Matthew Heaney]

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrna3tf3u.kg.lutz@taranis.iks-jena.de...
>  I have an several (at least two) interfaces with must be implemented
>  by the end user (compiler should require implementation). All of them
>  build a free(!) depedency tree. The simplest one is:
>
>      A -> B     B is an extended A and C is an extended A.
>      |    |     D combines both extensions (requiring both).
>      v    v
>      C -> D

You have to declare two "interface" types, B and C:

package P is
   type AType is abstract tagged limited null record;
   procedure A_Op (A : access AType) is abstract;

  type BType is abstract new A with null record;
  procedure B_Op (B : access BType) is abstract;
  type BAccess is access all BType'Class;

  type CType is abstract new A with null record;
  procedure C_Op (C : access CType) is abstract;
  type CAccess is access all CType'Class;
end P;

Now you want a D that you can view as either a B or a C:

with P; use P;
package Q is

  type DType is limited private;

  function BView (D : access DType) return BAccess;
  function CView (D : access DType) return CAccess;

private

  type D_BType (D : access DType) is new P.BType with null record;
  procedure A_Op (BPart : access D_BType);
  procedure B_Op (BPart : access D_BType);

  type D_CType (D : access DType) is new P.CType with null record;
  procedure A_Op (CPart : access D_CType);
  procedure C_Op (CPart : access D_CType);

  type DType is
     limited record
        BPart : aliased D_BType (DType'Access);
       CPart : aliased D_CType (DType'Access);
    end record;
end Q;

package body Q is
   function BView (D : access DType) return BAccess is
   begin
      return D.BPart'Access;
   end;

   function CView (D : access DType) return CAccess is
   begin
      return D.CPart'Access;
   end;

end Q;

Now you can use a D wherever you need a B or C, for example:

procedure Some_Op (B : access P.BType'Class);

declare
   D : aliased DTYpe;
begin
   Some_Op (BView (D'Access));
end;

Re: Sugestion to Multiple Inheritance

[Nick Roberts]

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrna3tf3u.kg.lutz@taranis.iks-jena.de...

> I'm looking for a design glue to build something like this:
>
>  I have an several (at least two) interfaces with must be implemented
>  by the end user (compiler should require implementation). All of them
>  build a free(!) depedency tree. The simplest one is:
>
>      A -> B     B is an extended A and C is an extended A.
>      |    |     D combines both extensions (requiring both).
>      v    v
>      C -> D
>
>  There are (generic) packages requiring special interfaces.
>
> I'd like to use abstract types and class wide programming, but this can't
be
> done in Ada naturally.


Taking the following example similar to your situation:


  type Respirant is abstract ...;
  procedure Breathe (Animal: in out Respirant; Air: ...);

  type Mammal is abstract new Respirant with ...;
  function Lactate (Animal: in Mammal) return Milk;

  type Arboreal is abstract new Respirant with ...;
  procedure Climb (Animal: in out Arboreal; Tree: ...);

  type Sloth is abstract new Arboreal, Mammal ...; --?


Maybe one solution is as follows:


  type Sloth is abstract new Respirant with ...;

  type Mammal_Aspect   is access all Mammal'Class;
  type Arboreal_Aspect is access all Arboreal'Class;

  function As_Mammal   (Animal: in Sloth) return Mammal_Aspect;
  function As_Arboreal (Animal: in Sloth) return Arboreal_Aspect;

  function Toes (Animal: in Sloth) return Two_Or_Three;


Thus, if you had:


  type Two_Toed_Sloth_As_Mammal is new Mammal with ...;
  -- implement Breathe and Lactate

  type Two_Toed_Sloth_As_Arboreal is new Arboreal with ...;
  -- implement Breathe (again!) and Climb

  type Two_Toed_Sloth is new Sloth with
    record
      Mammalianness: aliased Two_Toed_Sloth_As_Mammal;
      Arboreality:   aliased Two_Toed_Sloth_As_Arboreal;
    end record;

  -- implement Breathe (yet again!!)

  function As_Mammal (Animal: in Two_Toed_Sloth)
        return Mammal_Aspect is
  begin
    return Animal.Mammalianness'Access;
  end;

  function As_Arboreal (Animal: in Two_Toed_Sloth)
        return Arboreal_Aspect is
  begin
    return Animal.Arboreality'Access;
  end;

  function Toes (Animal: in Two_Toed_Sloth)
        return Two_Or_Three is
  begin
    return 2; -- ;-)
  end;


  Jenny: Two_Toed_Sloth;


You could then make Jenny climb to safety:


  Climb( As_Arboreal(Jenny).all, Nice_Tall_Tree );


Ugly, but it works, as they say. Hope this helps!

--
Best wishes,
Nick Roberts

Re: Sugestion to Multiple Inheritance

[Will]

Richard Riehle <richard@adaworks.com> wrote in message news:<3C3F2B7F.4F077FC0@adaworks.com>...
> polymorphic dispatching types. Grady Booch suggests that when you need
> MI, you really need it
Check out Mr Booch's recent interview on MSDN journal Feb issue.

Re: Sugestion to Multiple Inheritance

[Richard Riehle]

Hyman Rosen wrote:

> Richard Riehle wrote:
>  > With C++, MI is probably a disaster waiting to happen.
>
> Uh, oh. Drive-by shooting alert!
> Do you care to back up that statement with facts?

No.  It is well-known that I don't much like C++.   The more
I learn of it, and the more I am required to use it, the more
horrified I am by it.   Multiple inheritance is just one feature
I find, if not a disaster, at least, as you say, overly-complicated,
and inconvenient.

Richard Riehle

Re: Sugestion to Multiple Inheritance

[Hyman Rosen]

Richard Riehle wrote:
 > Multiple inheritance is just one feature

> I find, if not a disaster, at least, as you say, overly-complicated,
> and inconvenient.


Actually, the complications are in the compiler, because of technical
aspects of how objects must behave during their construction. In use,
MI works for C++ users pretty much exactly as they expect.

Re: Sugestion to Multiple Inheritance

[John English]

Hyman Rosen wrote:
> 
> Richard Riehle wrote:
>  > Multiple inheritance is just one feature
> 
> > I find, if not a disaster, at least, as you say, overly-complicated,
> > and inconvenient.
> 
> Actually, the complications are in the compiler, because of technical
> aspects of how objects must behave during their construction. In use,
> MI works for C++ users pretty much exactly as they expect.

Unless you have a diamond-shaped hierarchy:
              A
             / \
            B   C
             \ /
              D
in which case you get into the nasty world of virtual base classes
and the assorted surprises that they bring with them. Anyone who
finds that MI works "pretty much exactly as they expect" in this
situation has a better imagination than average, IMHO.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Sugestion to Multiple Inheritance

[Ole-Hjalmar Kristensen]

John English <je@brighton.ac.uk> writes:

> Hyman Rosen wrote:
> > 
> > Richard Riehle wrote:
> >  > Multiple inheritance is just one feature
> > 
> > > I find, if not a disaster, at least, as you say, overly-complicated,
> > > and inconvenient.
> > 
> > Actually, the complications are in the compiler, because of technical
> > aspects of how objects must behave during their construction. In use,
> > MI works for C++ users pretty much exactly as they expect.
> 
> Unless you have a diamond-shaped hierarchy:
>               A
>              / \
>             B   C
>              \ /
>               D
> in which case you get into the nasty world of virtual base classes
> and the assorted surprises that they bring with them. Anyone who
> finds that MI works "pretty much exactly as they expect" in this
> situation has a better imagination than average, IMHO.

I have lots of diamond-shaped hierarchies in my code to implement mixins.
It *USUALLY* works as expected by me. Other readers of the code tend to be 
confused. It is a nice idiom, but can be very confusing for people who have
not seen it before.


> 
> -----------------------------------------------------------------
>  John English              | mailto:je@brighton.ac.uk
>  Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
>  Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
>  University of Brighton    |    -- see http://burks.bton.ac.uk
> -----------------------------------------------------------------

Re: Sugestion to Multiple Inheritance

[Hyman Rosen]

Of course, in doing all this, you are doing pretty much
what a compiler that implements MI would be doing for you.

Re: Sugestion to Multiple Inheritance

[Lutz Donnerhacke]

* Hyman Rosen wrote:
>Of course, in doing all this, you are doing pretty much
>what a compiler that implements MI would be doing for you.

Exactly. Matthew showed also the impact of multiple inheritance by
duplicating the multiple included structure A. I'm pretty sure to find a way
without MI. Simply by designing the whole type more carefully and use
derivated packages.

  package Sorts is
     type Collection is tagged null record;
     procedure Sort (col : in out Collection);
     
     generic
     package Stable_Sorts
       type Stable_Collection is new Collection with null record;
       procedure Stable_Sort (col : in out Stable_Collection);
     end Stable_Sorts;
  end Sorts;

Usage:
  generic
    with package S is new Sort;
    with package SS is new S.Stable_Sorts (<>);
  package Algorithm is
    procedure Do_That (col : in out Stable_Collection'Class);
  end Algorithm;

;-) Thanx.

Re: Sugestion to Multiple Inheritance

[Lutz Donnerhacke]

* Stephen Leake wrote:
>lutz@iks-jena.de (Lutz Donnerhacke) writes:
>> * Stephen Leake wrote:
>> >lutz@iks-jena.de (Lutz Donnerhacke) writes:
>> >>      A -> B     B is an extended A and C is an extended A.
>> >>      |    |     D combines both extensions (requiring both).
>> >>      v    v
>> >>      C -> D
>> >
>> >I need more information about why C and B need to be independent types.
>> 
>> They do not need to be types at all. They are abstactions => interfaces.
>> Example: A describes a sort algorithm. B describes stableness. C describes
>> in-place-ness. D describes stable, in-place sort algorithms.
>
>Well, if they don't have to be types, you can easily do it in Ada. But
>all your complaints were that it could not be done with abstract Ada
>types.

I'm sorry for providing my solutions in the same posting asking for hints.
How can this be done easily?

Re: Sugestion to Multiple Inheritance

[Stephen Leake]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> * Stephen Leake wrote:
> >lutz@iks-jena.de (Lutz Donnerhacke) writes:
> >> * Stephen Leake wrote:
> >> >lutz@iks-jena.de (Lutz Donnerhacke) writes:
> >> >>      A -> B     B is an extended A and C is an extended A.
> >> >>      |    |     D combines both extensions (requiring both).
> >> >>      v    v
> >> >>      C -> D
> >> >
> >> >I need more information about why C and B need to be independent types.
> >> 
> >> They do not need to be types at all. They are abstactions => interfaces.
> >> Example: A describes a sort algorithm. B describes stableness. C describes
> >> in-place-ness. D describes stable, in-place sort algorithms.
> >
> >Well, if they don't have to be types, you can easily do it in Ada. But
> >all your complaints were that it could not be done with abstract Ada
> >types.
> 
> I'm sorry for providing my solutions in the same posting asking for hints.
> How can this be done easily?

Just write packages A, B, C, D, with appropriate subprogram
declarations in the spec, and appropriate comments saying what they
do. Then in the body of D, call the subprograms in B and C as
appropriate.

The Ada code will _not_ describe the inheritance structure, except in
the comments. Perhaps that is why you don't want to do this.

-- 
-- Stephe

Re: Sugestion to Multiple Inheritance

[Lutz Donnerhacke]

* Stephen Leake wrote:
>lutz@iks-jena.de (Lutz Donnerhacke) writes:
>> >> They do not need to be types at all. They are abstactions => interfaces.
>> >> Example: A describes a sort algorithm. B describes stableness. C describes
>> >> in-place-ness. D describes stable, in-place sort algorithms.
>> >
>> >Well, if they don't have to be types, you can easily do it in Ada. But
>> >all your complaints were that it could not be done with abstract Ada
>> >types.
>> 
>> I'm sorry for providing my solutions in the same posting asking for hints.
>> How can this be done easily?
>
>Just write packages A, B, C, D, with appropriate subprogram
>declarations in the spec, and appropriate comments saying what they
>do. Then in the body of D, call the subprograms in B and C as
>appropriate.
>
>The Ada code will _not_ describe the inheritance structure, except in
>the comments. Perhaps that is why you don't want to do this.

Let's try to code this:

package Sorts is
   function Sort (col : Collection) return Collection is abstract;
   procedure Sort (col : in out Collection) is abstract;
end package Sorts;

with Sorts;
package Stable_Sorts is
   function Sort renames Sorts.Sort;
end package Stable_Sorts;

with Sorts;
package Inplace_Sorts is
   procedure Sort renames Sorts.Sort;
end package Stable_Sorts;

with Stable_Sorts, Inplace_Sorts;
package Stable_Inplace_Sorts is
   procedure Sort renames ?;
end package;

Re: Sugestion to Multiple Inheritance

[Jim Rogers]

Lutz Donnerhacke wrote:

> 
> Let's try to code this:
> 
> package Sorts is
>    function Sort (col : Collection) return Collection is abstract;
>    procedure Sort (col : in out Collection) is abstract;
> end package Sorts;
> 
> with Sorts;
> package Stable_Sorts is
>    function Sort renames Sorts.Sort;
> end package Stable_Sorts;
> 
> with Sorts;
> package Inplace_Sorts is
>    procedure Sort renames Sorts.Sort;
> end package Stable_Sorts;
> 
> with Stable_Sorts, Inplace_Sorts;
> package Stable_Inplace_Sorts is
>    procedure Sort renames ?;
> end package;


Since the only sort procedure available to rename is
Inplace_Sorts.Sort, that must be the procedure you want to
rename. If, on the other hand, the Stable_Inplace_Sorts.Sort
must work with both the Stable_Sorts.Sort function and the
Inplace_Sorts.Sort procedure, you must not rename anything.
You must define the way those two Sort subprograms interact.
This means defining an entirely new Sort procedure for the
package Stable_Inplace_Sorts. This is one of the problems NOT
solved by multiple inheritance.

In fact, in this example, Stable_Inplace_Sorts would have
access to all the subprograms defined in Sorts. It would be
clearer to simply "with" or inherit from the Sorts
package directly.

Jim Rogers
Colorado Springs, Colorado USA

Re: Sugestion to Multiple Inheritance

[Matthew Heaney]

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrna48km8.ka.lutz@taranis.iks-jena.de...
> Exactly. Matthew showed also the impact of multiple inheritance by
> duplicating the multiple included structure A. I'm pretty sure to find a
way
> without MI. Simply by designing the whole type more carefully and use
> derivated packages.

It's not clear what you're trying to do here, using a type hierarchy.

Do you want a generic algorithm, that works for any kind of collection?  If
so, then what's wrong with the model that the C++ STL uses?  It doesn't use
tagged types, just generics.

You can do something very similar in Ada95:

generic

   type Iterator_Type is private;

   with function Is_Less (L, R : Iterator_Type) return Boolean is <>;

   with procedure Swap (L, R : Iterator_Type) is <>;

   with function "+" (L : Iterator_Type; R : Integer)
      return Iterator_Type is <>;

   with function "-" (L : Iterator_Type; R : Integer)
      return Iterator_Type is <>;

   with function "-" (L, R : Iterator_Type)
      return Integer is <>;

   with function "<" (L, R : Iterator_Type)
      return Boolean is <>;

   with function "=" (L, R : Iterator_Type)
      return Boolean is <>;

procedure Generic_Quicksort
  (First : in Iterator_Type;
   Back  : in Iterator_Type);

This will work for any collection that has an iterator.  It even works for
arrays.  The algorithm itself doesn't know anything about the collection
type or the item type.

Re: Sugestion to Multiple Inheritance

[Lutz Donnerhacke]

* Matthew Heaney wrote:
>"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
>> Exactly. Matthew showed also the impact of multiple inheritance by
>> duplicating the multiple included structure A. I'm pretty sure to find
>> a way without MI. Simply by designing the whole type more carefully and
>> use derivated packages.
>
>It's not clear what you're trying to do here, using a type hierarchy.
>
>Do you want a generic algorithm, that works for any kind of collection?

Yes.

>If so, then what's wrong with the model that the C++ STL uses?  It doesn't
>use tagged types, just generics.

Generics does not provide an abstract interface fullfilled by different
implemenations. I.e. a list-collection may generate a forward_iterator.
An algorithm requires forward_iterators aof any kind. The list-collection
might be instantiated by an array of limited types or a single-linked-list.
But every instatiation should provide the full interface of the iterator and
collection abstraction.

Sorry for beeing so vague, I'm still looking for a solution.

>You can do something very similar in Ada95:
>
>generic
>   type Iterator_Type is private;
>   with function Is_Less (L, R : Iterator_Type) return Boolean is <>;
>   with procedure Swap (L, R : Iterator_Type) is <>;
>   with function "+" (L : Iterator_Type; R : Integer)
>      return Iterator_Type is <>;
>   with function "-" (L : Iterator_Type; R : Integer)
>      return Iterator_Type is <>;
>   with function "-" (L, R : Iterator_Type)
>      return Integer is <>;
>   with function "<" (L, R : Iterator_Type)
>      return Boolean is <>;
>   with function "=" (L, R : Iterator_Type)
>      return Boolean is <>;
>procedure Generic_Quicksort
>  (First : in Iterator_Type;
>   Back  : in Iterator_Type);
>
>This will work for any collection that has an iterator.  It even works for
>arrays.  The algorithm itself doesn't know anything about the collection
>type or the item type.

Exactly. I thought about:
 generic
    type Iterator_Type is new Forward_Iterator with private;
 procedure Generic_XXX

getting the necessary interface from an abstaction.
    

Re: Sugestion to Multiple Inheritance

[Brian Rogoff]

On Mon, 21 Jan 2002, Lutz Donnerhacke wrote:
> * Matthew Heaney wrote:
> Generics does not provide an abstract interface fullfilled by different
> implemenations.

Yes, generics can do exactly that. Do you understand the signature idiom
in Ada 95?

What you don't get, that tagged types give you, is the same kind of
polymorphism at run time. You pay for that run time capability with run
time dispatch and the overhead of tagging.

> An algorithm requires forward_iterators aof any kind.

So you parameterize over a forward iterator signature, which looks
something like this

generic
    type Value_Type (<>) is limited private;
    type Pointer_Type is access Value_Type;
    type Iterator_Type is private;

    with procedure Incr (Iterator : in out Iterator_Type) is <>;
    with function Succ (Iterator : in Iterator_Type)
                       return Iterator_Type is <>;
    with function Get_Value (Iterator : Iterator_Type)
                            return Value_Type is <>;
    with procedure Set_Value (Iterator : in out Iterator_Type;
                              Value : in Value_Type) is <>;
    with function Get_Pointer (Iterator : Iterator_Type)
                              return Pointer_Type is <>;
    with function "=" (X, Y : Iterator_Type)
                        return Boolean is <>;
package Forward_Iterator_Signature is
-- Look, no body! This is a signature package.
end Forward_Iterator_Signature;

and your algorithms package will look something like this

with Forward_Iterator_Signature;
generic
    with package Iterators is new Forward_Iterator_Signature(<>);
    use Iterators;
package Forward_Algorithms is
    -- Nonmutating sequence algorithms

    generic
        with function "=" ( X, Y: in Value_Type ) return Boolean;
    function Find ( Start, Finish: in Iterator_Type;
                   Value: in Value_Type ) return Iterator_Type;

    generic
        with function "=" ( X, Y: in Value_Type ) return Boolean;
    function Adjacent_Find ( Start, Finish: in Iterator_Type )
                           return Iterator_Type;

    -- ... etc., etc.
end Forward_Algorithms;

-- Brian

Re: Sugestion to Multiple Inheritance

[Lutz Donnerhacke]

* Brian Rogoff wrote:
>Yes, generics can do exactly that. Do you understand the signature idiom
>in Ada 95?

Now I start to understand. Thanx.

>What you don't get, that tagged types give you, is the same kind of
>polymorphism at run time. You pay for that run time capability with run
>time dispatch and the overhead of tagging.

Of course. I was looking for an abstraction require a full instantiation.
Generics does this a small step later than abtract tagged types. (Besides
using tagged types for saving multiple implementations.) Without class wide
programming there is no run-time overhead, but a storage one.

>So you parameterize over a forward iterator signature, which looks
>something like this
>
>generic
>    type Value_Type (<>) is limited private;
>    type Pointer_Type is access Value_Type;
>    type Iterator_Type is private;
>
>    with procedure Incr (Iterator : in out Iterator_Type) is <>;
>    with function Succ (Iterator : in Iterator_Type)
>                       return Iterator_Type is <>;
>    with function Get_Value (Iterator : Iterator_Type)
>                            return Value_Type is <>;
>    with procedure Set_Value (Iterator : in out Iterator_Type;
>                              Value : in Value_Type) is <>;
>    with function Get_Pointer (Iterator : Iterator_Type)
>                              return Pointer_Type is <>;
>    with function "=" (X, Y : Iterator_Type)
>                        return Boolean is <>;
>package Forward_Iterator_Signature is
>-- Look, no body! This is a signature package.
>end Forward_Iterator_Signature;

Understand. Thank you. This seems to be the way Booch is working.

Re: Sugestion to Multiple Inheritance

[Brian Rogoff]

No problem! It may be worthwhile for someone to resuscitate the RPI SGL
library, which is based on the STL. When last I checked, it was still a
bit buggy, and I would prefer to avoid controlled types except when
necessary, but there were some good ideas there, and (at least in C++) I
prefer the generic approach to the OO approaches.

IMHO OOP is not as important as the programming world has made it out to
be, and should be used a lot less than it is.

-- Brian

On Mon, 21 Jan 2002, Lutz Donnerhacke wrote:

> * Brian Rogoff wrote:
> >Yes, generics can do exactly that. Do you understand the signature idiom
> >in Ada 95?
>
> Now I start to understand. Thanx.
>
> >What you don't get, that tagged types give you, is the same kind of
> >polymorphism at run time. You pay for that run time capability with run
> >time dispatch and the overhead of tagging.
>
> Of course. I was looking for an abstraction require a full instantiation.
> Generics does this a small step later than abtract tagged types. (Besides
> using tagged types for saving multiple implementations.) Without class wide
> programming there is no run-time overhead, but a storage one.
>
> >So you parameterize over a forward iterator signature, which looks
> >something like this
> >
> >generic
> >    type Value_Type (<>) is limited private;
> >    type Pointer_Type is access Value_Type;
> >    type Iterator_Type is private;
> >
> >    with procedure Incr (Iterator : in out Iterator_Type) is <>;
> >    with function Succ (Iterator : in Iterator_Type)
> >                       return Iterator_Type is <>;
> >    with function Get_Value (Iterator : Iterator_Type)
> >                            return Value_Type is <>;
> >    with procedure Set_Value (Iterator : in out Iterator_Type;
> >                              Value : in Value_Type) is <>;
> >    with function Get_Pointer (Iterator : Iterator_Type)
> >                              return Pointer_Type is <>;
> >    with function "=" (X, Y : Iterator_Type)
> >                        return Boolean is <>;
> >package Forward_Iterator_Signature is
> >-- Look, no body! This is a signature package.
> >end Forward_Iterator_Signature;
>
> Understand. Thank you. This seems to be the way Booch is working.
>

Re: Sugestion to Multiple Inheritance

[Dmitry A. Kazakov]

On Tue, 22 Jan 2002 16:55:51 +0000, Brian Rogoff
<bpr@bpr.best.vwh.net> wrote:

[...]

>I prefer the generic approach to the OO approaches.
>
>IMHO OOP is not as important as the programming world has made it out to
>be, and should be used a lot less than it is.

If I substitute ADT for OO, will above remain correct then? [I presume
also that "OO approach" =  "class wide programming] If it so, then I
strongly disagree.

Regards,
Dmitry Kazakov

Re: Sugestion to Multiple Inheritance

[Brian Rogoff]

On Wed, 23 Jan 2002, Dmitry A. Kazakov wrote:
> On Tue, 22 Jan 2002 16:55:51 +0000, Brian Rogoff
> <bpr@bpr.best.vwh.net> wrote:
>
> [...]
>
> >I prefer the generic approach to the OO approaches.
> >
> >IMHO OOP is not as important as the programming world has made it out to
> >be, and should be used a lot less than it is.
>
> If I substitute ADT for OO, will above remain correct then?

I have no idea what point you are trying to make. OO approaches usually
provide some mix of inheritance (though Common List defstruct has
inheritance without OOP I think) and run time polymorphism/dynamic
dispatch. ADTs are an orthogonal feature/capability.

To be specific, I much prefer a language like ML (even SML, which has no
objects) to one like Java. Of course, I'd rather have OCaml (or Ada) which
allows me to have OO features when they are appropriate. I just think that
OO features are not frequently needed or desirable.

You may certainly disagree, as there are still nations which allow that.

-- Brian

Re: Sugestion to Multiple Inheritance

[Dmitry A. Kazakov]

On Fri, 25 Jan 2002 00:09:44 +0000, Brian Rogoff
<bpr@bpr.best.vwh.net> wrote:

>On Wed, 23 Jan 2002, Dmitry A. Kazakov wrote:
>> On Tue, 22 Jan 2002 16:55:51 +0000, Brian Rogoff
>> <bpr@bpr.best.vwh.net> wrote:
>>
>> [...]
>>
>> >I prefer the generic approach to the OO approaches.
>> >
>> >IMHO OOP is not as important as the programming world has made it out to
>> >be, and should be used a lot less than it is.
>>
>> If I substitute ADT for OO, will above remain correct then?
>
>I have no idea what point you are trying to make. OO approaches usually
>provide some mix of inheritance (though Common List defstruct has
>inheritance without OOP I think) and run time polymorphism/dynamic
>dispatch. ADTs are an orthogonal feature/capability.

In my view if you strip away myths from OO, the rest will be plain
ADT, i.e. an ability to build new types from old ones. Inheritance and
polymorphism are just methods [among many others] to ease that
process.

>To be specific, I much prefer a language like ML (even SML, which has no
>objects) to one like Java. Of course, I'd rather have OCaml (or Ada) which
>allows me to have OO features when they are appropriate. I just think that
>OO features are not frequently needed or desirable.

Let's forget objects and classes [it is enough to have types and
variables] as well as implementation/compilation issues [for a minute
(:-))]. Now, what is wrong with:

1. Any type* can be derived from
2. Any type* may have initialization and finalization
3. A dispatching argument can by of any type*

[*] class-wide types are excluded.

>You may certainly disagree, as there are still nations which allow that.

Yes, becase IMO the rational part of OO is ADT and I believe that
practically any program requires some form of ADT. Then I'd prefer ADT
to generics.

Regards,
Dmitry Kazakov