Re: [squeak-dev] Message>>#= & Message>>#hash

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Message>>#= & Message>>#hash

David T. Lewis
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 lookkupClass instance variable relevant for comparisons? I am
guessing not, since we already have #analogousCodeTo: for that type of
comparison.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: [Cuis-dev] [squeak-dev] Message>>#= & Message>>#hash

David T. Lewis

On Mon, Nov 19, 2018 at 04:16:51PM -0800, Eliot Miranda via Cuis-dev wrote:

> Hi David,
>
> On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <[hidden email]> 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.

That feels correct to me also. But implementation details and bikeshedding
aside, I would be happy if "Message allInstances asSet asArray" could answer
a reasonably small collection of different-looking things. So +1 to the
change, with or without consideration of lookupClass.

Dave