Message>>#= & Message>>#hash
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? _,,,^..^,,,_ best, Eliot
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
Hi David, On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <lewis@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. Dave
_,,,^..^,,,_ best, Eliot
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 <lewis@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.
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
On 20 Nov 2018, at 01:16, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi David,
On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <lewis@mail.msen.com <mailto:lewis@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.
To me this looks like a good change, yes. Marcus
Wait, Message is the one used internally by the system. It doesn't have #= and #hash because it didn't need it. *MessageSend* is the one for external use, and it already defines #= and #hash. On Mon, Nov 19, 2018 at 11:32 AM Eliot Miranda <eliot.miranda@gmail.com> 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?
_,,,^..^,,,_ best, Eliot
participants (4)
-
Chris Muller -
David T. Lewis -
Eliot Miranda -
Marcus Denker