Point taken, but remember, at this stage I haven't even attempted to
change behaviour or protocol - all I am doing is adding an instance
variable. According to OO lore, this really shouldn't have any effect
on the system (althought obviously it does). Adding a method in
Collection that returns a two arg comparison block solves the
problem, other methods can then refer to this block by calling
the method. Problem is, the block will be the same for all
instances. To have some collection instances that do
identity comparison, and some that use = or other arbitrary
methods (that can change dynamically) each instance needs
to store its own comparison block. I was hoping to extend this
idea to add other pluggable behaviour in the collections.

Due to the limitations of single inheritance, an OrderedCollection
can't behave as a set, and an array can't be sorted. Dependents
notification, buffering, synchronisation, mutability etc are all other
issues
that are hard to factor into the hierarchy.

I was thinking along the lines of
add: anItem
    self addBlock value: anItem

By plugging in different addBlocks, different instances of the same class
can or cannot have
the following behaviour, dependent on the addBlock.

* duplicate elimination (set behaviour) or other 'screening' of items to be
added (nil is allowed or not, etc.
* dependents notification
* overwrite existing elements or add to end, beginning etc (insert,
overwrite, append prepend)
* mutability ( read-only or read-write behaviour)
* sorting or not, depending on where the item is added.

similar arguments apply to the remove block, at: put: etc.

Having pluggable methods should keep the number of collection classes and
their methods
(protocols) smaller, and provide something akin to multiple inheritance.
With this approach
you can make a collection instance where items can be added but not removed,
with no duplicates
in sorted order with update notification, without creating a new class, or
having an explosion
of classes with different combinations of these properties.

Peter

-----Original Message-----
From: Raab, Andreas <Andreas.Raab at disney.com>
To: DanI at wdi.disney.com <DanI at wdi.disney.com>; 'squeak at cs.uiuc.edu'
<squeak at cs.uiuc.edu>
Date: Thursday, February 18, 1999 10:48 AM
Subject: Collection hierarchy (was: RE: Hardware or System Incompatibility)


>> PS,  I have been trying to move the PluggableDictionary
>> concept into the base collection classes. That is, i want
>> all collections to use a comparison block (instance variable) for
>> includes: anItem etc. This needs to be pluggable for
>> each collection instance. However, putting instance variables
>> into the base collections brings squeak down almost immediately,
>> or it hangs indefinitely. I notice Dolphin warns against doing this.
>> VW nc 3.0  tries valiantly, but runs out of memory and crashes
>> (I have tried it on computers with 24 and 32 mb ram). Is the
>> collection hierachy 'untouchable' or am I doing something wrong??
>>
>The Collection hierarchy is not untouchable - but implicitly changing
>classes like Array or MethodDictionary *will* kill you. So, you be very
>careful about the implications of the modification you provide ;-)
>
>  Andreas
>--
>PLEASE NOTE NEW EMAIL ADRESS!
>
>+===== Andreas Raab ========= (andreasr at wdi.disney.com) ==+
>| Walt Disney Imagineering        Phone: +1 818 544 5016  I
>I Glendale, CA                    Fax:   +1 818 544 4544  I
>+======< http://isgwww.cs.uni-magdeburg.de/~raab >========+
>
>