Re: Container Library?

[Tim Teulings <tim@edge.ping.de>]

Hallo!

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

Isn't this the so called fragile baseclass problem? VO already uses an
empty record named Object as baseclass for most of its objects. That
why I recently proposed to include such a definition into the oo2c
library.

>    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

Is this really necessary? Isn't it a feature to put any type of data
into a container?

I want to throw some other points:

The baseclass could also provide elementary methods for persistance.
The problem is that it is difficult to seperate the baseclass for
containers and a baseclass for persistance (if persistence is handled
by type bound methods). So baseclass should have some load and store
functionality.

Also it may be good to not only implement some baseclass Object but
also a hierachie of classes inheriting from Object, which define
generic methods for comparison and that like. So a list could work on
objects but it also exists a method sort with casts object to
Comparable. Using adapters (which is a good idea) this problem however
could be solved differently.

The code I had written as a start for such a library already used such
class hierachie.

-- 
Gru...
       Tim.