Re: Container Library?

[Peter Froehlich <pfroehli@ics.uci.edu>]

Hi all!

Michael made some very true observations about the mail from
mkgardne@cs.uiuc.edu and I won't repeat them here. However, I want to
comment on the following:

At 11:15 AM +0100 4/24/98, Michael van Acken wrote:

>Therefore I suggest something like this:
>
>MODULE LinkedList;
>  IMPORT
>    Out, StdTypes;
>
>  TYPE
>    (* type for elements of a linked list *)
>    Element* = POINTER TO ElementDesc;
>    ElementDesc = RECORD
>      next, prev : Element;
>(**)  car : StdTypes.Object;  (* well, that's how it's called in LISP
>*)
>    END;
>
>where StdTypes.Object is a suitable empty record.  Data is stored in
>extensions of the type `Object'.

   Aside from the naming issue involved, this of course makes it necessary
that every application that wants to use any part of the container library
must then derive its classes from StdTypes.Object. Although this is better
than the other approach, it does not really cure the problem, but on the
other hand, a proper cure would only be possible by extending the language
(ANYREC and ANYPTR-like types) which is not in the spirit of the OOC
project AFAIK.

   Additionally it is not necessarily true that the class StdTypes.Object
should be completely empty. For example, if one wants to be able to provide
run-time type-checked containers, there has to be a method like

   PROCEDURE (self: Object) IsSupertypeOf (other: Object): BOOLEAN;
   BEGIN
     RETURN other IS Object;
   END IsSupertypeOf;

that each derived class must override in order to perform relevant
type-tests at run-time. This could of course be avoided if Types.Mod would
provide a suitable procedure, e.g.

   PROCEDURE Extends (base, extended: Type): BOOLEAN;

which it currently does not (though it could be implemented using BaseOf()
in a loop, but that would be very inefficient). Better ideas?

>This operator could be implemented as a type-bound procedure.
>Advantage:
>o the record, to which the type-bound proc is bound, could be used to
>  pass parameters to it, and the result back to the caller
>o the operator procedure is visible to module `Types'; a very useful
>  thing if you are working with persistent objects

   I really don't understand both of these comments; please clarify. I
personally would replace this "operator" thing with Iterator classes.

>Here the "adapter" is an extension of `Object', but Mark's statements
>still apply.  This uses more memory, and it needs an additional
>indirection for element access.  But memory is cheap, and the
>indirection doesn't effect the overall complexity of list operations.
>The big pro is, of course, that the data type is much more flexible
>this way.  IMO this is more important than minor efficiency
>considerations when designing a general purpose library module.

   True again... :-)

By(T)e...        /  Department of Information and Computer Science  \
        Peter... \ University of California - Irvine, CA 92697-3425 /