Hi,

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.

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.
Different proxies could need different amount of Object functionality.
In my case "ProtoObject sublcass: #DebuggableProtoObject" with some more
Object functionality moved up there might have solved it.

so define:

ProtoObject>>effectiveClass
   ^self class

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.

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 ..)

In Squeak there is the extra complications from compect classes, and I
a few classes are treated specially in the VM.

Probably this is related to new/basicNew. The current #class would
perhaps better be called #basicClass.

/Mats