On Wed, Oct 15, 2014 at 11:53 AM, Richard Sargent <
[email protected]> wrote:
> Eliot Miranda-2 wrote
> > On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
>
> > richard.sargent@
>
> >> wrote:
> >> One of the best things about Smalltalk is how easily we can say what we
> >> mean. I think you would be better off creating a method named something
> >> like
> >> #hasSameEffectAs: to answer what you are presently using #= to do, and
> >> change #= to answer the, in my opinion, more sensible "is the same as"
> >> that
> >> we conventionally think of #= meaning.
> >>
> >
> > But that's the point. #= has to mean something and having it mean #==
> > isn't useful, so one has to choose some value-based semantic for
> > CompiledMethod>>#= and the one that's there is useful. Defining what #=
> > means for some value type is far easier than defining what it might mean
> > for something as complex as a CompiledMethod. The definition in
> > Squeak/Pharo has been useful to me in implementing a closure-based
> system,
> > so I'm unapologetic about the current definition. It is a good one but
> it
> > doesn't preclude defining others.
>
> An interesting response. You ignored the point that e.g. #hasSameEffectAs:
> provides greater clarity and add an argument against something I didn't
> say.
>
It's a given. But the selector still isn't perfectly informative, see
below. And what's the effect? The effect when executed, so why not
hasSameEffectWhenExecuted:? It's a mouthful.
I also don't think defining equality for a CompiledMethod is particularly
> difficult. If I were to recompile a method's source code, I would get a new
> instance of a CompiledMethod that would, in my opinion, be equal to the one
> already installed in the class (and perhaps cached in the VM's
> optimizations). So one would be able to say that we would not replace an
> existing CompiledMethod with an equal one. The current implementation of #=
> has no such characteristic, since it proclaims a CompiledMethod named #a to
> be equal to one named #z.
>
And for some uses that is correct, one names a /is/ equal to one named z,
even though their selectors differ. For example if you do the following:
aClass compile: 'a ^1'; compile: 'b ^ 1'.
aClass compiledMethodAt: #a put: aClass >> #b
then "aClass new a" still answers 1. It's only if one introspects
(thisContext method selector, opens the debugger, etc) that one sees that
the selector doesn't match. If you go back to Smalltalk-80 you'll see that
compiled methods didn't store their selector and to find out their selector
one searched the method dictionary of the method's method class. As far as
what most methods do (excluding introspecting code) the selector is merely
a cache of the key in the relevant method dictionary.
So #hasSameEffect: *doesn't* mean what one might think it means for some
uses (it doesn't only depend on the method in question, but on usage,
whether the method is used in an introspective context, etc). So naming a
more explanatory selector is more difficult than you might think.
The blue book say #= means "Answer whether the receiver and the argument
> represent the same component." The current implementation does so only for
> some, in my opinion, counter-intuitive definition of "same component".
>
Well Smalltalk-80 says
Answer true if the receiver and the argument represent the same object
and false otherwise. If = is redefined in any subclass, consider also
redefining the message hash.
and that's just as vague (AFAIA the blue book doesn't define what a
component is), because whether objects are equal or not depends on usage.
In the end the system is full of definitions of #= which are more or less
generally useful in various contexts. Things are easy for the arithmetic
types, but for more complex objects there are always caveats
| s1 s2 |
s1 := Set new.
s1 add: s1.
s2 := Set new.
s2 add: s2.
s1 = s2
doesn't terminate. So should Set's #= be called isEqualIfNonRecursive: ?
No. Its limited #= is fine in practice and much better than Smalltalk-80's
original fall back to #==. But it is not a perfect equality. Neither is
CompiledMethod's. But it being imperfect is not an argument for changing
it to another, inevitably also flawed definition without good reason.
--
> View this message in context:
> http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
--
best,
Eliot
