It is interesting. In base Squeak, the only time that lookupClass is set is, well, never(!). There is a setter method, but it isn't called is base Squeak. It is checked a couple of times, but unless there is hidden machinery in the VM that sets it, it isn't actually ever used.
Unless someone decided to use it in their code.
-cbc
On Tue, Nov 20, 2018 at 9:06 AM Chris Muller asqueaker@gmail.com wrote:
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@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@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