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

Andreas Raab Andreas.Raab at gmx.de
Mon Aug 12 16:05:54 UTC 2002


Cool. Thanks for checking it.
 
Cheers,
  - Andreas

-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of
Nathanael Schärli
Sent: Monday, August 12, 2002 5:20 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: RE: [BUG][FIX?]3.2 bug adding class variables


Andreas (and Boris)
 
You are right Andreas (and Boris). I didn't have Squeak around when I
answered Boris' email, and by just briefly looking at the changeset I
thought that he wanted to get rid of the special treatment of
metaclasses in the condition "(oldClass == nil or: [oldClass isMeta
not])". Now I see that he didn't and it is still ensured that there is
always a sole instance of each metaclass.
 
Thus, as far as I can see, Boris' fix is completely safe and should
probably be inclueded into the official image...
 
Cheers,
Nathanael
 
BTW: I messed around with some of the critical classes after filing in
Boris' changeset, and I also run my "class hierarchy consistency check
method". Everything worked perfectly fine!
 
 
 -----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of
Andreas Raab
Sent: Monday, August 12, 2002 4:38 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: RE: [BUG][FIX?]3.2 bug adding class variables



Nathanael,
 
I believe Boris' proposed fix is correct but I'll wait for your
confirmation. The reason for having the condition of "oldClass == nil
or:[oldClass isMeta not]" is that we *don't* want to clone
non-metaclasses (if we did meta classes have more than a single instance
which breaks fundamental assumptions in the recompilation process later)
so a new class/metaclass has to be created but it should certainly share
everything that was present in the old class (if any).
 
Cheers,
  - Andreas
 
-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of
Nathanael Schärli
Sent: Monday, August 12, 2002 2:41 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: RE: [BUG][FIX?]3.2 bug adding class variables



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/97fe994e/attachment.htm


More information about the Squeak-dev mailing list