Hi Christoph,

On Thu, Oct 1, 2020 at 10:51 AM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> Hi Eliot,
>
> I'm not deep in this stuff, but I always try to keep maximum flexibility
> in terms of polymorphy when designing any interface in Squeak. Thus my
> naive choice would be option 3, ignore it and hope the user knows what
> they're doing. Using of #isKindOf: etc. often can lead to problems, for
> example, imagine an association being wrapped within a proxy or an
> ObjectTracer ... Just my 2 cents :)
>

Well, it's easy to put checking in for EphemeronDictionary, because there
things really matter. (& thx for your real-time response ;-) )

In looking at the code it strikes me that arrayClass should also be
implemented on the instance size to match associationClass.  This affects
only OrderedCollection new which sends arrayClass form the class side; all
other sends are instance size.  And that's easy to deal with:

OrderedCollection class>>#new: anInteger
^ self basicNew setCollection: (self arrayType new: anInteger)
=>
OrderedCollection class>>#new: anInteger
| instance |
^(instance := self basicNew) setCollection: (instance arrayType new:
anInteger)

Any objections?

> Best,
>
> Christoph
> <http://www.hpi.de/>
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
> *Gesendet:* Donnerstag, 1. Oktober 2020 19:44:46
> *An:* The general-purpose Squeak developers list
> *Betreff:* [squeak-dev] Ephemerons and Dictionaries
>
> 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...
>
> 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 associationClass.  So that means Dictionary should override
> atNewIndex:put:.
>
> 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
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201001/b030f7e2/attachment.html>