This might be a pandora's box though.  If you take things further, you
could implement two separate collection hierarchies...one would
implement the abstract notions of collections, and the other would
implement the concrete structures.  For example:

Dictionary would support the interface we all know and love.  We would
then add a few other concrete Dictionaries like: SmallDictionary,
MediumDictionary, LargeDictionary,
ReallyLargePersistentDictionary...then Dictionary would use one of the
other dictionaries based on some policy settings.  As it grows in size,
it would adopt different implementations based on those policies.

Someone once told me that old versions of IBM Smalltalk actually did
this.

- Stephen 

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Lex Spoon
> Sent: Monday, August 05, 2002 2:39 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: [ENH] Ten Percent Faster Morphic! (with conversion)
> 
> 
> 
> > Could we make all really small hashed structures do linear searches?
> > 
> > - Stephen
> 
> 
> You beat me to it!  With a little refactoring, you can put 
> this strategy in Set and make every hashed collection do it.  
> It will be a smidgen slower, probably, than using an 
> OrderedCollection.  But then you don't have to manually 
> figure out which of your collections will be small and write 
> uglier code to manage them.  Furthermore, you don't have to 
> worry about performance when the collections grow.
> 
> One idea, by the way, is to use an object to hold the 
> searching and placement strategy. Then you replace al the "if 
> size < 4" statements by a polymorphic call to the strategy 
> object.  In fact, if you look up Strategy (I think it's 
> Strategy) in the design patterns book, then a very relevant 
> example pops up.  :)
> 
> 
> -Lex
> 
>