[squeak-dev] Message>>#= & Message>>#hash
asqueaker at gmail.com
Tue Nov 20 17:05:24 UTC 2018
It sounds good, but an Inbox submission would go a long way to
understanding exactly what you mean esp. re: understanding this
special condition with the lookupClass being nil... and whether it
deserves a first-class name or not...
On Tue, Nov 20, 2018 at 4:10 AM Levente Uzonyi <leves at caesar.elte.hu> 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
> > Dave
> > _,,,^..^,,,_
> > best, Eliot
More information about the Squeak-dev