Monticello bug; #class and #== optimalizations
squeak1 at continentalbrno.cz
Wed Jun 30 08:04:27 UTC 2004
The second part of my mail isn't related to Monticello, sorry.
When I save new snapsot, Snapsoo Brower shows:
nil subclass: #MyClass
During loading of snapshot Monticello opens this warning window:
This package depends on the following classes:
You must resolve these dependencies before you will be able to load these
----- Original Message -----
From: "Avi Bryant" <avi at beta4.com>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, June 30, 2004 9:41 AM
Subject: Re: Monticello bug; #class and #== optimalizations
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
> 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
> message calls. For example, message #class is never called, because
> 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