Support of algebraic operations on sets
nicolas cellier
ncellier at ifrance.com
Fri Jun 15 21:18:18 UTC 2007
Blake a écrit :
> On Fri, 15 Jun 2007 10:23:56 -0700, sig <siguctua at gmail.com> wrote:
>
>>> > Or remove them from second book.
>>>
>>> new do: [:k | book2 removeKey: k].
>>>
>> instead of:
>> book2 difference: (book1 intersection: book2)
>>
>> can't you see the difference?
>
> Hmmm. In algebra:
>
> 2+2*4 = 10
>
> In Smalltalk:
>
> 2+2*4 = 16
>
> Not to belabor the point, but Smalltalk isn't math or algebra. It does
> have its own internal consistency ("purity", some might say), though,
> and it's not reasonable to expect to conform to those of another
> discipline. To my mind Smalltalk is more like, well, talking than math.
> Which is why the above equation makes sense to me: ("Add two and two
> together...multiply by four...."). Messages above all, right?
>
> Smalltalk's vocabulary has value because it is well defined and has been
> well defined for a long time. It's not hard to create a new class that
> does what you expect; are you suggesting that decades of code and
> documentation be broken because this interpretation of
> "difference"--which is exactly what I would expect if someone said,
> "tell me the difference between this dictionary and that one"--is
> somehow offensive to you on mathematical grounds?
>
>
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
More information about the Squeak-dev
mailing list
|