2009/7/28 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 2009/7/28 Paolo Bonzini <bonzini at gnu.org>:
>>
>>>> I propose that the intersection of two Dictionaries should either
>>>>    a)  Return the intersection of the keys of the Dictionaries.
>>>>         Not an intuitive answer either but better than now.
>>>>         For example, what would you expect the intersection of two
>>>> MethodDictionaries
>>>>         to be?
>>
>> I second this.  It is extremely unlikely that someone is using to intersect
>> values, since the unique values of a Dictionary (the "Set"-like values) are
>> actually the keys.
>>
>
> I would rather tend to explicitly type (a keys intersection: b keys).
>
>>>>    b)  Generate the shouldNotImplement error.
>>>>
>>>
>>> c) make Dictionary be not the subclass of Set, then questions, like
>>> wrong #intersection: symmetry will auto-become a non-issue. :)
>>
>> Paolo
>>
>>
>
> I already implemented c) once for fun.
> See the thread starting at
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/117840.html
> ... and my arguments for moving Dictionary and Set under a common
right. i remember that topic :)
The summary of it is below:

--------------
Blake, I can understand your argument, Smalltalk cannot serve every
different logics. Though they can eventually coexist with subclasses
sometimes. Choices have to be made. Lots of ambiguity come from our
language: different guys have differnt understandings (even math
language is ambiguous and strongly contextual, and that's part of its
power for sure).

But common, no math means no geometry, no windows, no menu, no Smalltalk
math/algebra is everywhere/behind/inside Smalltalk.

And enforcing the well-behaved / least surprising / strongly logical
kernel with good mathematical background cannot be a bad thing.

I feel that's what's in the mind of sig.

Beside, most Smalltalk have Associations compared only on key. So this
pecularity of Squeak can be argued and should have been argued. Maybe
it's a very arbitrary choice designed for a very particular application
without deeper thought of all implications and without consensus. Maybe
it's a very good choice superior to other Smalltalk...
I can't say if sig point of view is right or wrong. But i can say he is
right to open the question.

The fact that Dictionary are subclasses of Set means there are a kind of
  Set. So its element should be unique, so Association should compare
only on key. But in this case, Dictionary with equal keys and different
values should be equal, something we all find... Hmm surprising...

So, making Association comparing on values seems to be a remedy to this
surprise. But in this case, Dictionary don't behave like Set anymore...
So the logic would be to detach them from Set hierarchy. Only the list
of keys is a set...

Maybe we kept it there for saving a few methods duplication? But when it
is necessary to define more methods to contradict super behaviour than
methods we inherit, maybe it's time for a move in hierarchy. Leave your
super and be adopted by a new family.

Nicolas
--------------

so, if Dictionary is a subclass of Set, then , as any Set it should
conform with Set rules, i.e.:

(setA difference: setB) = (setB difference: setA)
and
(setA union: setB) = (setB union:setA)

where setA, setB could be any (sub)instance of Set.

And if its not (as in fact Dictionary behaves), then it should not
belong to Set hierarchy.


> HashedCollection
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/117894.html
>
> Nicolas
>


-- 
Best regards,
Igor Stasenko AKA sig.