Hi Eliot,

On Thu, 1 Oct 2020, Eliot Miranda wrote:

> Hi All,
> 
>     to be able to ease EphemeronDicitonary into the system easily I'd like to clean up adding associations to Dictionary.  It seems to me there's a partial implementation of choosing an association class appropriate for a
> dictionary in the implementors of associationClass: Dictionary>>#associationClass, WeakKeyDictionary>>#associationClass, WeakValueDictionary>>#associationClass, (& in my image STON class>>#associationClass).  This seems
> workable; an EphemeronDictionary would simply add associationClass ^ Ephemeron and we're done, except not quite...

What's the definition of Ephemeron?

> 
> First, HashedCollection does not use associationClass, but it implements atNewIndex:put: and it strikes me that atNewIndex:put: for Dictionary really should check for the thing being added at least includingBehavior: self

HashedCollection does not use associationClass because HashedCollections 
in general (e.g. Sets) may store any object in their internal array not 
just Associations.
Dictionary introduces #associationClass because it only stores 
associations (except for MethodDictionary of course).

#atNewIndex:put: is a private method. Its senders must ensure that the
arguments will not corrupt the receiver's internal state

> associationClass.  So that means Dictionary should override atNewIndex:put:.

Can you give a bit more information about how EphemeronDictionary should 
work?


Levente

> 
> But what should happen in atNewIndex:put: if the object being added isn't appropriate?  Do we
> - raise an error? (that's my preference, but I've got limited use cases in my head)
> - replace the association with one of assocationClass? (seems dangerous to me but maybe someone needs this or the existing system does this anyway)
> - ignore it and hope the user knows what they're doing?
> 
> 
> 
> _,,,^..^,,,_
> best, Eliot
> 
>