CompiledMethod>>hash can produce clashes
We found an issue where CompiledMethods can produce the same hash event within the same MethodDictionary. Reported here: https://pharo.fogbugz.com/f/cases/14246/CompiledMethod-hash-can-produce-clas... <https://pharo.fogbugz.com/f/cases/14246/CompiledMethod-hash-can-produce-clas...> Cheers, Max
I responded... On Wed, Oct 15, 2014 at 7:11 AM, Max Leske <maxleske@gmail.com> wrote:
We found an issue where CompiledMethods can produce the same hash event within the same MethodDictionary. Reported here:
https://pharo.fogbugz.com/f/cases/14246/CompiledMethod-hash-can-produce-clas...
Cheers, Max
-- best, Eliot
Eliot Miranda-2 wrote
I responded...
I have to disagree with your recommendation. You say that you intend #= to mean "has the same effect as" rather than "is the same as". 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. $0.02 worth and worth everything you paid for it. :-) Richard -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Richard, On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < richard.sargent@gemtalksystems.com> wrote:
Eliot Miranda-2 wrote
I responded...
I have to disagree with your recommendation. You say that you intend #= to mean "has the same effect as" rather than "is the same as".
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. $0.02 worth and worth everything you paid for it. :-)
Richard
-- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- best, Eliot
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. 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. 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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Wed, Oct 15, 2014 at 11:53 AM, Richard Sargent < richard.sargent@gemtalksystems.com> 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-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- best, Eliot
Richard Sargent 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.
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.
@Richard That doesn't seem to be a good example for what your trying to say. Given... [1] SomeClass>>a "original instance" ^1 [2] SomeClass>>a "recompiled instance" ^1 [3] SomeClass>>z ^1 ...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ? But [1]=[2] remains true, and just as useful for your example. @Max I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that? cheers -ben
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".
-- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash. The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent: Collection methods select: #isAbstract. All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is). So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod. In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing). Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality. Doru On Fri, Oct 17, 2014 at 9:34 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com "Every thing has its own flow"
On 17.10.2014, at 09:37, Tudor Girba <tudor@tudorgirba.com> wrote:
But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality.
Well, actually itâs both #hash and #=. First the set tries to find a suitable place for the element using the elements hash. If that place is already taken it then checks equality. Since the equality definition is mostly the same (same literals, same byte codes etc.), the second element is rejected because itâs already in the set.
Doru
On Fri, Oct 17, 2014 at 9:34 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com <mailto:btc@openInWorld.com>> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... <http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784...> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
-- www.tudorgirba.com <http://www.tudorgirba.com/>
"Every thing has its own flow"
Exactly. So, the problem with Set is not in hash at all, but in equality. Of course, we can still enhance hash, but we should first focus on equality. And I am also of the opinion that equality should take the name of the selector and even the name of the class into account. Doru On Fri, Oct 17, 2014 at 9:52 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 09:37, Tudor Girba <tudor@tudorgirba.com> wrote:
But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality.
Well, actually itâs both #hash and #=. First the set tries to find a suitable place for the element using the elements hash. If that place is already taken it then checks equality. Since the equality definition is mostly the same (same literals, same byte codes etc.), the second element is rejected because itâs already in the set.
Doru
On Fri, Oct 17, 2014 at 9:34 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
On 17 Oct 2014, at 11:12, Tudor Girba <tudor@tudorgirba.com> wrote:
Exactly. So, the problem with Set is not in hash at all, but in equality. Of course, we can still enhance hash, but we should first focus on equality.
And I am also of the opinion that equality should take the name of the selector and even the name of the class into account.
From a modelling standpoint it sounds as if one object (CompiledMethod) is used for two different things which results in the conflicting ideas about implementing equality and hashing. A CompiledMethod should hold a CompiledCode object while adding the selector and class. The CompiledCode object could then be equivalent or even be optionally shared among similar methods (like all those implementing ^self).
Just an external observation / idea.
Doru
On Fri, Oct 17, 2014 at 9:52 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 09:37, Tudor Girba <tudor@tudorgirba.com> wrote:
But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality.
Well, actually itâs both #hash and #=. First the set tries to find a suitable place for the element using the elements hash. If that place is already taken it then checks equality. Since the equality definition is mostly the same (same literals, same byte codes etc.), the second element is rejected because itâs already in the set.
Doru
On Fri, Oct 17, 2014 at 9:34 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
On 17.10.2014, at 11:39, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Oct 2014, at 11:12, Tudor Girba <tudor@tudorgirba.com> wrote:
Exactly. So, the problem with Set is not in hash at all, but in equality. Of course, we can still enhance hash, but we should first focus on equality.
And I am also of the opinion that equality should take the name of the selector and even the name of the class into account.
From a modelling standpoint it sounds as if one object (CompiledMethod) is used for two different things which results in the conflicting ideas about implementing equality and hashing. A CompiledMethod should hold a CompiledCode object while adding the selector and class. The CompiledCode object could then be equivalent or even be optionally shared among similar methods (like all those implementing ^self).
Just an external observation / idea.
Yes, pretty much what I was thinking. I donât know what the consequences would be for the VM though...
Doru
On Fri, Oct 17, 2014 at 9:52 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 09:37, Tudor Girba <tudor@tudorgirba.com> wrote:
But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality.
Well, actually itâs both #hash and #=. First the set tries to find a suitable place for the element using the elements hash. If that place is already taken it then checks equality. Since the equality definition is mostly the same (same literals, same byte codes etc.), the second element is rejected because itâs already in the set.
Doru
On Fri, Oct 17, 2014 at 9:34 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
--Â Marcus Denker Sent with Airmail On 17 Oct 2014 at 11:45:23, Max Leske (maxleske@gmail.com) wrote:
On 17.10.2014, at 11:39, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Oct 2014, at 11:12, Tudor Girba <tudor@tudorgirba.com> wrote:
Exactly. So, the problem with Set is not in hash at all, but in equality. Of course, we can still enhance hash, but we should first focus on equality.
And I am also of the opinion that equality should take the name of the selector and even the name of the class into account.
From a modelling standpoint it sounds as if one object (CompiledMethod) is used for two different things which results in the conflicting ideas about implementing equality and hashing. A CompiledMethod should hold a CompiledCode object while adding the selector and class. The CompiledCode object could then be equivalent or even be optionally shared among similar methods (like all those implementing ^self).
Just an external observation / idea.
Yes, pretty much what I was thinking. I donât know what the consequences would be for the VM though... Yes, I think, too, that many of the problems with CompiledMethod come from the fact that we âabuseâ a low level object in a context where people want a higher level concept. Marcus
On 17.10.2014, at 11:12, Tudor Girba <tudor@tudorgirba.com> wrote:
Exactly. So, the problem with Set is not in hash at all, but in equality. Of course, we can still enhance hash, but we should first focus on equality.
And I am also of the opinion that equality should take the name of the selector and even the name of the class into account.
Did you read Eliotâs argument? He needs the equality definition to find duplicates. I donât agree with you (anymore). The selector and the class are simply associated with a given CompiledMethod. But the CompiledMethod is still one without a name and without a class it is installed in. From that point of view, neither the class nor the selector should be included in the definition of equality. I do agree however, that it kind of goes against the way programmers tend to think of methods, thus my idea (which I did not think through at all) to have something like CompiledMethodWrapper, that lets CompiledMethod be what it is and abstracts the object for use with class and selector (see my answer to Benâs e-mail). Cheers, Max
Doru
On Fri, Oct 17, 2014 at 9:52 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 17.10.2014, at 09:37, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality.
Well, actually itâs both #hash and #=. First the set tries to find a suitable place for the element using the elements hash. If that place is already taken it then checks equality. Since the equality definition is mostly the same (same literals, same byte codes etc.), the second element is rejected because itâs already in the set.
Doru
On Fri, Oct 17, 2014 at 9:34 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com <mailto:btc@openInWorld.com>> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... <http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784...> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
-- www.tudorgirba.com <http://www.tudorgirba.com/>
"Every thing has its own flow"
-- www.tudorgirba.com <http://www.tudorgirba.com/>
"Every thing has its own flow"
Hi Max, On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
Surely the issue is that "aClass methods" should answer an IdentitySet right?
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Eliot (phone)
On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Max,
On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com <mailto:btc@openInWorld.com>> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
Surely the issue is that "aClass methods" should answer an IdentitySet right?
Well, in the case of my example that wouldnât change anything. As soon as you put the methods into a set youâll end up with less entries than before again. Selectors are unique per class anyway so I donât quite see the benefit of using an IdentitySet over an OrderedCollection (or a Bag for that matter), except for making it more obvious that the result of the message #methods doesnât need to be filtered further. I should add that the code, the student who discovered the clash wrote, looked more like this: result := Set new. Collection methods do: [ :m | m isAbstract ifTrue: [ result add: m ] ]. Max
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... <http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784...> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
Eliot (phone)
2014-10-17 15:49 GMT+02:00 Max Leske <maxleske@gmail.com>:
On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Max,
On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
Surely the issue is that "aClass methods" should answer an IdentitySet right?
Well, in the case of my example that wouldnât change anything. As soon as you put the methods into a set youâll end up with less entries than before again. Selectors are unique per class anyway so I donât quite see the benefit of using an IdentitySet over an OrderedCollection (or a Bag for that matter), except for making it more obvious that the result of the message #methods doesnât need to be filtered further.
I should add that the code, the student who discovered the clash wrote, looked more like this:
result := Set new. Collection methods do: [ :m | m isAbstract ifTrue: [ result add: m ] ].
Max
Why not just keep a dictionary, like methodDictionary select: #isAbstract or something like that...
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
Eliot (phone)
On 17.10.2014, at 15:52, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2014-10-17 15:49 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>:
On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
Hi Max,
On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com <mailto:btc@openInWorld.com>> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
Surely the issue is that "aClass methods" should answer an IdentitySet right?
Well, in the case of my example that wouldnât change anything. As soon as you put the methods into a set youâll end up with less entries than before again. Selectors are unique per class anyway so I donât quite see the benefit of using an IdentitySet over an OrderedCollection (or a Bag for that matter), except for making it more obvious that the result of the message #methods doesnât need to be filtered further.
I should add that the code, the student who discovered the clash wrote, looked more like this:
result := Set new. Collection methods do: [ :m | m isAbstract ifTrue: [ result add: m ] ].
Max
Why not just keep a dictionary, like methodDictionary select: #isAbstract or something like thatâ¦
Youâre right of course, thereâs no need to put methods into a set. The code is from an exercise and the students arenât used to Smalltalk, so they end up with all sorts of code.
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... <http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784...> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
Eliot (phone)
Hi Max, On Oct 17, 2014, at 7:24 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 15:52, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2014-10-17 15:49 GMT+02:00 Max Leske <maxleske@gmail.com>:
On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Max,
On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
Surely the issue is that "aClass methods" should answer an IdentitySet right?
Well, in the case of my example that wouldnât change anything. As soon as you put the methods into a set youâll end up with less entries than before again. Selectors are unique per class anyway so I donât quite see the benefit of using an IdentitySet over an OrderedCollection (or a Bag for that matter), except for making it more obvious that the result of the message #methods doesnât need to be filtered further.
I should add that the code, the student who discovered the clash wrote, looked more like this:
result := Set new. Collection methods do: [ :m | m isAbstract ifTrue: [ result add: m ] ].
Max
Why not just keep a dictionary, like methodDictionary select: #isAbstract or something like thatâ¦
Youâre right of course, thereâs no need to put methods into a set. The code is from an exercise and the students arenât used to Smalltalk, so they end up with all sorts of code.
And so they learn...
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Eliot (phone)
Eliot (phone)
On 17.10.2014, at 16:41, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Max,
On Oct 17, 2014, at 7:24 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 17.10.2014, at 15:52, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote:
2014-10-17 15:49 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>:
On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
Hi Max,
On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com <mailto:btc@openInWorld.com>> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
Surely the issue is that "aClass methods" should answer an IdentitySet right?
Well, in the case of my example that wouldnât change anything. As soon as you put the methods into a set youâll end up with less entries than before again. Selectors are unique per class anyway so I donât quite see the benefit of using an IdentitySet over an OrderedCollection (or a Bag for that matter), except for making it more obvious that the result of the message #methods doesnât need to be filtered further.
I should add that the code, the student who discovered the clash wrote, looked more like this:
result := Set new. Collection methods do: [ :m | m isAbstract ifTrue: [ result add: m ] ].
Max
Why not just keep a dictionary, like methodDictionary select: #isAbstract or something like thatâ¦
Youâre right of course, thereâs no need to put methods into a set. The code is from an exercise and the students arenât used to Smalltalk, so they end up with all sorts of code.
And so they learn...
:p
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... <http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784...> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
Eliot (phone)
Eliot (phone)
Hi Max, On Oct 17, 2014, at 6:49 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Max,
On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske@gmail.com> wrote:
On 17.10.2014, at 02:46, Ben Coman <btc@openInWorld.com> wrote:
Richard Sargent 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. 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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash.
The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent:
Collection methods select: #isAbstract.
All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is).
Surely the issue is that "aClass methods" should answer an IdentitySet right?
Well, in the case of my example that wouldnât change anything. As soon as you put the methods into a set youâll end up with less entries than before again.
No. An IdentitySet uses #== and identityHash so that won't be the case. Also IIRC. anIdentitySet collect: answers another IdentitySet.
Selectors are unique per class anyway so I donât quite see the benefit of using an IdentitySet over an OrderedCollection (or a Bag for that matter), except for making it more obvious that the result of the message #methods doesnât need to be filtered further.
Well then (IdentitySet withAll: aClass methods) collect: will not lose elements. You'd have exactly the same issue if you tried to collect the set of all literals in the system. Unless you used an IdentitySet you'd collect only the different values, not all literals. Or any set of all objects that represent values.
I should add that the code, the student who discovered the clash wrote, looked more like this:
result := Set new. Collection methods do: [ :m | m isAbstract ifTrue: [ result add: m ] ].
So change it to IdentitySet new. This is good for the student to encounter. It is one of the essential differences between OO and functional languages. We have state and identity.
Max
So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod.
In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing).
Cheers, Max
cheers -ben
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". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Eliot (phone)
Cheers, Eliot
Ben Coman wrote
Richard Sargent 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.
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.
@Richard
That doesn't seem to be a good example for what your trying to say. Given...
[1] SomeClass>>a "original instance" ^1
[2] SomeClass>>a "recompiled instance" ^1
[3] SomeClass>>z ^1
...you seem to be saying that its useful to know if [1]=[2], but imply that is invalidated by [2]=[3] ?
But [1]=[2] remains true, and just as useful for your example.
Ben, I believe you are correct. I did not think deeply enough about how using #= would work. In retrospect, it looks like my hypothesized scenarios would not be problematic. But I will stand by my argument about naming methods. The philosophical technique Reductio ad Absurdum will be useful here. If I began a method declaration as follows, everyone would agree it was bad. fred: another "Answer whether I have the same effect as @another." I believe almost everyone would agree the mistake in that is that the comment should be unnecessary because the method name should explain its purpose. One of the best heuristics I have ever encountered for naming things is to start by "explaining to a colleague" (perhaps an imaginary one) what the thing does, then strip out every word which does not affect the meaning. [This last step would almost certainly prevent the inclusion of phrases like "when executing" in a CompiledMethod method, in my opinion.]
@Max
I guess to call it a bug, you bumped into a different use case where [2]=[3] is problematic. Can you describe that?
cheers -ben
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".
-- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4785... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (8)
-
Ben Coman -
Eliot Miranda -
Marcus Denker -
Max Leske -
Nicolas Cellier -
Richard Sargent -
Sven Van Caekenberghe -
Tudor Girba