<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2716.2200" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=307502912-12082002><FONT face=Arial color=#0000ff size=2>Boris 
and Andreas,</FONT></SPAN></DIV>
<DIV><SPAN class=307502912-12082002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=307502912-12082002><FONT face=Arial color=#0000ff size=2>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&nbsp;introduced the&nbsp;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.</FONT></SPAN></DIV>
<DIV><SPAN class=307502912-12082002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=307502912-12082002><FONT face=Arial color=#0000ff 
size=2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=307502912-12082002><FONT face=Arial color=#0000ff 
size=2>Nathanael</FONT></SPAN></DIV>
<DIV><SPAN class=307502912-12082002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
  squeak-dev-admin@lists.squeakfoundation.org 
  [mailto:squeak-dev-admin@lists.squeakfoundation.org] <B>On Behalf Of </B>Boris 
  Gaertner<BR><B>Sent:</B> Sunday, August 11, 2002 9:33 PM<BR><B>To:</B> 
  squeak-dev@lists.squeakfoundation.org<BR><B>Subject:</B> Re: [BUG][FIX?]3.2 
  bug adding class variables<BR><BR></FONT></DIV>
  <DIV><BR>Bob Arning &lt;<A 
  href="mailto:arning@charm.net">arning@charm.net</A>&gt; reported that one 
  cannot at the same time<BR>add an instance variable and a class variable to a 
  class. The bug is not<BR>very dramatic, because both modifications can be done 
  one by one, but<BR>it is nevertheless an annoying bug.<BR><BR>Bob 
  wrote:<BR><BR>&gt;in 3.2 at 4653, all works as expected, but in the latest 
  (4917),<BR>&gt;the class variable is not accepted.<BR>&gt;The key point is 
  that adding an instance var and a class var at the same<BR>&gt;time will only 
  change the instance var<BR><BR>This bug is also present in 3.3a 
  (#4954).<BR><BR>Debugging (in the 3.2 image) reveals that the new class looses 
  its<BR>classPool when, 
  in<BR>ClassBuilder&gt;&gt;recompile:from:to:mutate:,&nbsp; the 
  statement<BR><FONT face=Courier size=2></FONT></DIV>
  <DIV><FONT face=Courier size=2>newClass _ self reshapeClass: 
  oldClass<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to: 
  newClass super: newClass superclass</FONT>.<BR>is executed.<BR><BR>In 2.7., 
  the class variables of&nbsp; newClass survive that statement.<BR><BR>The 
  interesting things happen earlier.<BR><BR>In 
  ClassBuilder&gt;&gt;name:inEnvironment:subclassOf:type:instanceVariableNames:<BR>&nbsp;&nbsp; 
  classVariablenames:poolDicitionaries:category:unsafe:<BR><BR>we have this 
  statement:<BR><BR><FONT face=Courier size=2>&nbsp;newClass _ 
  self<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; newSubclassOf: 
  newSuper<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type: 
  type<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; instanceVariables: 
  instVars<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from: 
  oldClass<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unsafe: 
  unsafe.<BR><BR></FONT>This is where the new class is created. Following that 
  statement I added<BR>(both in 3.2 final and in 2.7) this piece of 
  code:<BR><BR><FONT face=Courier size=2>(oldClass notNil and: [newClass 
  classPool == oldClass classPool])<BR>&nbsp;&nbsp;&nbsp; ifTrue: [self 
  halt]<BR>&nbsp;&nbsp;&nbsp; ifFalse: [self halt].<BR><BR></FONT>Then I did 
  what Bob described (added an instance variable and a class<BR>variable to a 
  class definition and saved the class definition with "accept")<BR>and I saw 
  that in&nbsp; 2.7&nbsp; oldClass and newClass share the same 
  classPool,<BR>whereas in 3.2&nbsp; they don't.<BR><BR>A comparision 
  of<BR><BR><FONT face=Courier 
  size=2>ClassBuilder&gt;&gt;newSubclassOf:type:instanveVariables:from:unsafe:<BR></FONT><BR>reveals 
  that in&nbsp; 2.7 the newClass is cloned from the oldClass if the<BR>oldClass 
  is not nil<BR>whereas in 3.2 newClass is cloned from oldClass if the 
  following<BR>condition evaluated to false:<BR>&nbsp;<FONT face=Courier 
  size=2>(oldClass == nil or:[oldClass isMeta not])<BR><BR></FONT>In 3.3a this 
  condition came with change set 4854 (ar 2/15/2002),<BR>for 3.2 I cannot find 
  the change set.<BR><BR><BR>I think that it would help to copy the&nbsp; 
  classPool&nbsp; from&nbsp; oldClass<BR>when oldClass is not nil. The attached 
  change set does exactly<BR>that and it seems to work.<BR><BR>Note however that 
  my change set is only a proposal. Andreas or<BR>Nathanael could you please 
  have a look at that code.<BR>Thank you very 
  much.<BR><BR>Greetings<BR>Boris<BR><BR><BR></DIV></BLOCKQUOTE></BODY></HTML>