[ENH] bytecodePrimClass and bytecodePrimEquivalentaremessage
sends. Double dispatch #== (was Re: [ENH] RE: Does#classdeserve to
be a very-special shortcut bytecode anymore?)
Stephan Rudlof
sr at evolgo.de
Sun Jan 6 20:24:57 UTC 2002
Rob Withers wrote:
>
> At 02:07 AM 1/6/2002, you wrote:
> >Rob Withers wrote:
> > >
> > > The additional problem I had with #== is when the proxy is the
> > > argument. So I changed ProtoObject to double dispatch #== to
> > > basicEquivalence: which calls primitive 110. Is this reasonable
> > > performance-wise, do you think?
> >
> >Independent from the performance question I have the impression that
> >changing the semantics of #== is a very radical thing: it is thought to
> >compare oops.
> >Isn't it better to use #= instead for comparison of to be proxied objects?
> >Or some other self written comparison method?
>
> Well,yes, I suppose it is radical. The comment in ProtoObject>>#== (and
> now ProtoObject>>#basicEquivalence:) says,
>
> "Do not redefine the message == in any other class! Essential. No Lookup.
> Do not override in any subclass."
>
> We have changed the No Lookup part, with the bytecodePrimEquivalent change,
> and my Proxy classes are reimplementing both of these equivalence methods
> to forward the equivalence test to the target object (that Proxant (tm) :-).
>
> We should/must have the ability to decide whether to override this method,
> as well as #class. In the current system, we cannot because of the
> primitive. With the primitve changes, I can decide to override #== and
> #class in my class and provide an alternate definition for them. The
> double dispatch is required to allow the argument a chance to supply any
> special equivalence behavior. In the system I am thinking of, I want the
> proxied object and the proxy itself to be identical when compared.
But they are not identical because one is a proxy, the other not: so you
need methods like #isProxy or similar at least to get this information.
> I want
> existing classes, which use #= or #== to respect this. I could implement
> my own but that would only work for classes I write.
>
> The method nextObject and nextInstance both need to work correctly for
> Proxies. The redirector code (I posted it after the one you replied to)
> uses primitives in the way that Stephene Pair discusses. I got the idea
> from him. All of these system methods are written for the redirector as
> accepting the receiver as an argument.
To give you an idea about what I'm thinking: Using proxies for objects
residing in different Squeak
- OS (for me Linux) processes,
- processes on other machines.
Then I'd have different semantics for e.g. #nextInstance meant as
- inside one (OS) process or
- between different ones (on the same or different machines).
Greetings,
Stephan
>
> cheers,
> Rob
>
> >Greetings,
> >
> >Stephan
> >
> >
> >PS: Haven't worked with proxies so far, but some ideas which realizations
> >*would* (not in the near future) lead to a work with proxies.
> >
> >--
> >Stephan Rudlof (sr at evolgo.de)
> > "Genius doesn't work on an assembly line basis.
> > You can't simply say, 'Today I will be brilliant.'"
> > -- Kirk, "The Ultimate Computer", stardate 4731.3
--
Stephan Rudlof (sr at evolgo.de)
"Genius doesn't work on an assembly line basis.
You can't simply say, 'Today I will be brilliant.'"
-- Kirk, "The Ultimate Computer", stardate 4731.3
More information about the Squeak-dev
mailing list
|