Mats Nygren wrote:

> It seems to me that a reasonable compromise is to have more than one
> message for getting a "class". #effectiveClass for instance. And then use
> that. For proxies like ObjectOut this seems to be a good things, it really
> do need to have the class ObjectOut to get its behavior, but on other
> occasions it should answer the class of what is out on disk.

ObjectOut defines the message #xxxClass, with implementation
"<primitive: 111>", which is identical to #class as defined in Object.
So when ObjectOut needs to get its behaviour, it can use #xxxClass. 

> I ran into problems similar to this when trying to construct my first
> proxies (gof decorators). The debugger got completly confused. At least
> in this case I think the debugger could be rewritten with two related
> class concepts. #class remaining hardwired, but often #effectiveClass
> should be used, giving proxies (using doesNotUnderstand:) oportunities
> to make a special effectiveClass. But probably the
> "ProtoObject subclass: #Object"-situation isnt fully designed yet.

The cool thing about ProtoObject, is that it does *not* define a #class
message. #class is defined in Object. 

The sad thing about the VM is, that sending of the #class message is
optimised out. So you *can* send #class to a ProtoObject, although it is
*not* defined there.

As for debugging transparant proxies, two cases can be made: Do you want
to debug the proxy or the thing the proxy points to? It is clear that
both cases are valid ... So how's the debugger going to know? 

I'd go for a standard behaviour of debugging the thing the proxy points
to. After all, we're talking about *transparant* proxies, right? To
debug the proxies you'll have to return to basic stuff, such as
"Transcript show: foo asString". Ugly, I know ...

> and redefine it in proxies and be careful to use effectiveClass instead
> of class in most places. If I understand your problem this would solve
> it but demand a perhaps unreasonable amount if class/effectiveClass
> substitutions.

I'd have to change the entire image, so, yes, I think I can consider
that as an unreasonable amout of changes ;-)

> There is something distressing in having class fully polymorphic since
> polymorphism is defined in terms of class. (To get x's class send it the
> class-message, which method should be used to do that?, that is determined
> by x's class, so send it the class message ..)

That's the nice thing about meta-level programming: you can shoot
yourself in the foot in *interesting* ways :-)

--
"You are more than the sum       Johan Fabry - Johan.Fabry at vub.ac.be
 of what you consume.            Vrije Universiteit Brussel
 Desire is not an occupation."   Programming Technology Lab, Room 10F709
  -- KMFDM                       Pleinlaan 2, 1050 Brussels, Belgium