Re: New Tree Example (was Re: MI - clutching at straws)

Re: New Tree Example (was Re: MI - clutching at straws)

[Robert I. Eachus]

    Gee, this is getting complex.  I'm going to try to break it into
separate threads.  (I'll be in Pittsburgh most of next week, so
silence will not construe consent to anything. :-)

In article <1992Sep15.140840.3405@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.in
formatik.rwth-aachen.de (Peter Klein) writes:

   Sorry, but I still don't see how you handle polymorphism with generics.
   One last example on this: Suppose you have some container class, let's
   say a list. In this list, you want to store objects of different types.
   In the implementation of the list, you don't know what types, you don't
   even know how many. In fact, you *shouldn't* know this, because it has
   nothing to do with the list itself. Now, please, how do you do this with
   generics?

   I'll answer the last question first...

   package Mixed_Lists is

      type List is private;

      function Is_Empty(L: List) return Boolean;
      function New_List...
      -- all the usual operations which don't mention elements.

      generic
        type Item is private;
      package New_Elements is
        procedure Append(L: in out List; E: in Item);
        ...
      end New_Elements;

   private
     ...
   end Mixed_Lists;

  -- You can do all this with just a little attention to magic in
  -- Ada 83.  (Each instance of New_Elements gets a unique tag
  -- from Mixed_Lists, and does run-time type checking when
  -- removing things from lists by matching tags.  Of course, in
  -- Ada 9X you can use tagged types to do that automatically.)

    Having said all that, this is the wrong way round, especially in
Ada 9X.  First create the node type, which may just be a placeholder,
then mix in the lists, then derive the various element types from the
node type:

     type Node_Type is tagged record null; end record;

     generic
       type Element is tagged private;
     package Lists is
       type Item is new Element with null; -- (I don't like the syntax either.)
       type List is private;
       -- define list operations here. (But make sure they are class wide.)
     private
       ...
     end Lists;

     package Node_Lists is new Lists(Node_Type);
    
     package Identifiers is
       type Identifier_Node is new Node_Lists.Item with private;
       -- operations on identifiers go here.
     private
       ...
     end Identifiers;
 
     -- etc., etc.

  So far so good, but now we can go one step further.  Since
the abstraction of mixed lists is a generally useful one, and there is
no particular need for the parent list element type to have any
attibutes other than those associated with lists, there is no
particular reason to make the list package a generic, and in fact
there is no reason to use multiple inheritance either. :-)
        
--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...