Monticello bug; #class and #== optimalizations

Avi Bryant avi at
Wed Jun 30 07:41:42 UTC 2004

On Jun 30, 2004, at 12:34 AM, Pavel Křivánek wrote:

> Hi all,
> Monticello has a problem with this class construction:
> ProtoObject subclass: #MyClass
>             instanceVariableNames: 'object'
>             classVariableNames: ''
>             poolDictionaries: ''
>             category: 'MyClasses.
> MyClass superclass: nil
> It forgets the last line with superclass specification.
> I'm using it for proxy objects. Instances of MyClass have one variable 
> to
> store a real receiver of messages. MyClass resends messages using
> doesNotUnderstand mechanism.
> doesNotUnderstand: aMessage
>             ^ aMessage sendTo: object.
> It works well but there is one problem - Squeak uses optimalization of 
> some
> message calls. For example, message #class is never called, because 
> Squeak
> uses special bytecode 199 (bytecodePrimClass). Real class of proxy 
> object is
> returned instead of receiver class.

I don't understand in what way this last part is related to Monticello. 
  I can see that Monticello might have trouble saving/loading a class 
with nil superclass - is that the problem?  I always use subclasses of 
ProtoObject for proxies, which usually works well enough.  But if you 
really need a nil superclass, then yes, we can try to support that.  
Can you give more info about the errors you are getting when you try?


More information about the Squeak-dev mailing list