To make things more clear, the current implementation of Behavior >> #hash 
has two negative side effects:
- behaviors stored in collections relying on the hash value (e.g. Set, 
Dictionary) will have to be rehashed whenever a behavior is renamed
- objects using Behavior >> #hash to implement their own #hash, like what 
Eliot just did to Message will suffer from the same issue. So Sets and 
Dictionaries holding those kind of objects will have to be rehashed as 
well upon the rename of the behavior.

My questions related to this:
- why does Behavior >> #hash rely on the name instead of identity?
- do we want to fix those issues mentioned above or do we just say that 
one should not rename classes and expect things to work?

Levente

On Tue, 20 Nov 2018, Levente Uzonyi wrote:

> On Mon, 19 Nov 2018, Eliot Miranda wrote:
>
>> Hi David,
>> 
>> On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <lewis at mail.msen.com> wrote:
>>       On Mon, Nov 19, 2018 at 09:32:17AM -0800, Eliot Miranda wrote:
>>       > Hi All,
>>       >
>>       >     In VisualWorks Message implements #= & #hash naturally; two 
>> messages
>>       > whose selectors and arguments are #= are also equal.  But in Cuis, 
>> Squeak
>>       > and Pharo Message inherits #= and #hash from Object, i.e. uses 
>> identity
>>       > comparison.  This is, to say the least, annoying.  Any objections 
>> to
>>       > implementing comparing in Message to match VisualWorks?
>>       >
>>
>>       That sounds like an obviously good thing to do :-)
>>
>>       Is the lookupClass instance variable relevant for comparisons? I am
>>       guessing not, since we already have #analogousCodeTo: for that type 
>> of
>>       comparison.
>> 
>> 
>> For me it is relevant.  Two messages with different lookupClasses, e.g. one 
>> with nil and one with a specific class, represent different messages, one a 
>> normal send one a super send.  So my changes in
>> waiting include lookupClass in both hash and =.  I don't think it makes 
>> much difference, but the incompatibility with VisualWorks, while 
>> regrettable, feels correct to me.
>
> What about Behavior >> #hash? It uses the name of the class, which is fine as 
> long as you don't rename your classes while you store them in hashed 
> collections.
>
> Levente
>
>>
>>       Dave
>> 
>> 
>> _,,,^..^,,,_
>> best, Eliot
>> 
>