[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