[BUG][FIX?]3.2 bug adding class variables

Nathanael Schärli n.schaerli at gmx.net
Mon Aug 12 12:40:56 UTC 2002


Boris and Andreas,
 
That's definitely an interesting issue, and it seems to be related to
the fix of the ClassBuilder Andreas and me did earlier this year.
Altough your fix seems to be pretty obvious and straight forward, I'm
not quite sure whether there are no negative implications.
(Unfortunately, I don't remember exactly why Andreas introduced the
condition "(oldClass == nil or: [oldClass isMeta not])", but I'm pretty
sure that there *was* a reason for treating metaclasses differently.
Well, I'll have a more detailed look at it when I have some time tonight
and I'll let you know.
 
Cheers,
Nathanael
 

-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of Boris
Gaertner
Sent: Sunday, August 11, 2002 9:33 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: [BUG][FIX?]3.2 bug adding class variables



Bob Arning <arning at charm.net> reported that one cannot at the same time
add an instance variable and a class variable to a class. The bug is not
very dramatic, because both modifications can be done one by one, but
it is nevertheless an annoying bug.

Bob wrote:

>in 3.2 at 4653, all works as expected, but in the latest (4917),
>the class variable is not accepted.
>The key point is that adding an instance var and a class var at the
same
>time will only change the instance var

This bug is also present in 3.3a (#4954).

Debugging (in the 3.2 image) reveals that the new class looses its
classPool when, in
ClassBuilder>>recompile:from:to:mutate:,  the statement

newClass _ self reshapeClass: oldClass
                to: newClass super: newClass superclass.
is executed.

In 2.7., the class variables of  newClass survive that statement.

The interesting things happen earlier.

In
ClassBuilder>>name:inEnvironment:subclassOf:type:instanceVariableNames:
   classVariablenames:poolDicitionaries:category:unsafe:

we have this statement:

 newClass _ self
       newSubclassOf: newSuper
       type: type
       instanceVariables: instVars
       from: oldClass
       unsafe: unsafe.

This is where the new class is created. Following that statement I added
(both in 3.2 final and in 2.7) this piece of code:

(oldClass notNil and: [newClass classPool == oldClass classPool])
    ifTrue: [self halt]
    ifFalse: [self halt].

Then I did what Bob described (added an instance variable and a class
variable to a class definition and saved the class definition with
"accept")
and I saw that in  2.7  oldClass and newClass share the same classPool,
whereas in 3.2  they don't.

A comparision of

ClassBuilder>>newSubclassOf:type:instanveVariables:from:unsafe:

reveals that in  2.7 the newClass is cloned from the oldClass if the
oldClass is not nil
whereas in 3.2 newClass is cloned from oldClass if the following
condition evaluated to false:
 (oldClass == nil or:[oldClass isMeta not])

In 3.3a this condition came with change set 4854 (ar 2/15/2002),
for 3.2 I cannot find the change set.


I think that it would help to copy the  classPool  from  oldClass
when oldClass is not nil. The attached change set does exactly
that and it seems to work.

Note however that my change set is only a proposal. Andreas or
Nathanael could you please have a look at that code.
Thank you very much.

Greetings
Boris




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20020812/0ae506b8/attachment.htm


More information about the Squeak-dev mailing list