[BUG] StringMorph needs textColor inst var and uses color inst var

Diego Gomez Deck DiegoGomezDeck at ConsultAr.com
Sat May 4 21:47:41 UTC 2002


Hello...

Other posibility is to repair all the instances, so after the class is modified, run some like:

  StringMorph allSubInstances do:[:each | each textColor: Color black]

My two cents,

Diego Gomez Deck

>Ken,
>
>As soon as you submit a modified class definition, all existing 
>instances of the class (and of its subclasses) are mutated.  If 
>you've added an instance variable, all instances immediately acquire 
>the new instance variable, with value nil.
>
>So if you want your redefined class to be robust in the face of 
>pre-existing instances, just make certain the new code you write will 
>not fail when run on behalf of those pre-existing instances that have 
>nil values in the slot you added.
>
>One straightforward approach -- which you have alluded to -- would be 
>to define #textColor as something like:
>
>textColor
>	^ textColor ifNil: [textColor := Color black]
>
>... do this *before* you modify drawOn:.  Then, in your drawOn:, use 
>this getter rather than a direct inst-var reference.
>
>
>Use of a lazy getter such as this is traditional, but not essential. 
>Alternatively, you could have also have done this safely directly 
>within your #drawOn: method itself, if you preferred, as long as you 
>were careful to handle the nil case there.
>
>   -- Scott
>
>
>At 2:28 PM -0500 5/4/02, Ken Causey wrote:
>>Yes.  I belive the exact problem is that I added a new inst var 
>>(textColor) to StringMorph, and then modified StringMorph>>drawOn: 
>>so that this inst var was used as the color for the text.  Any 
>>existing instances freaked out at that point.  It's not clear to me 
>>what happens with existing instances when new inst vars are added to 
>>the class.  I'm guessing the existing instances had no such instance 
>>variable textColor and when the new drawOn: method tried to use 
>>it...  Otherwise, even if the instance var existed, it's value would 
>>have bin nil, still not good.
>>
>>However, it now occurs to me that I may have avoided this if I had 
>>simple not made the mistake of referencing the instance variable 
>>directly and had instead use the getter (with lazy initialization) 
>>that I had taken the trouble to create.  IF (big assumption) the new 
>>instance variable existed then lazy initialization would have filled 
>>it in.
>>
>>So, the question is, if you modify the Class definition (add 
>>instanced variable for example) are existing instances still based 
>>on the old definition?  If so (which I suspect is the case) how does 
>>one go about recreating these instances for such ubiquitous classes 
>>such as StringMorph?
>>
>>Theory #1:  Modify the class definition to add the instance 
>>variable. Don't modify any existing methods to use this method. 
>>Save the image and quit the image.  Restart the image.  Be sure to 
>>make use of lazy initialization to make sure that any access to the 
>>variable returns a useful value.  Modify all methods appropriately.
>>
>>What do you think?  Would this do the job?
>>
>>Thanks,
>>
>>Ken Causey
>>
>>Scott Wallace wrote:
>>>Ken,
>>>
>>>It's not that objects can't happily mutate on the fly in Squeak -- 
>>>that happens all the time.  It's very common for people to add 
>>>instance variables to classes that have existing instances.  Squeak 
>>>is extremely robust about this.
>>>
>>>The problem, rather, is more likely to be that the code you wrote 
>>>in your modified StringMorph drawOn: method raised an error.
>>>
>>>Because StringMorphs are used in the title bars of System Windows, 
>>>every attempt to report this error -- or any error -- will result 
>>>in a fresh error (since a pre-debug Notifier is itself a 
>>>SystemWindow, and hence needs to have a StringMorph drawn in its 
>>>title bar.) That's probably why your image ran away from you.
>>>
>>>   -- Scott
>>>
>>>
>>>At 4:44 PM -0500 5/3/02, Ken Causey wrote:
>>>
>>>>/me replies to himself.
>>>>
>>>>So okay, I decide to play with fixing this.  Add an inst var of
>>>>textColor, add lazy init getter and setter.  Modify drawOn: and whoops!
>>>>my image is locked and alt-. doesn't help.  Clearly I've swept the rug
>>>>out from under a host of existing StringMorphs in my image.
>>>>
>>>>So, how do I go about making this sort of change?  I can't at the moment
>>>>see how to modify the image and not having StringMorph instances active.
>>>>
>>>>Ken
>>>>
>>>>On Fri, 2002-05-03 at 16:09, Ken Causey wrote:
>>>>
>>>>>  I'm playing around and try some code like:
>>>>>
>>>>>  (s _ SystemWindow labelled: 'Boogah')
>>>>>     openInHand.
>>>>>  s addMorph: (StringMorph new
>>>>>         contents: 'Comments:';
>>>>>         color: Color black)
>>>>>     frame: (0 at 0.0 corner: 1 at 0.2).
>>>>>
>>>>>  And I don't see any StringMorph in the window.  I start looking around
>>>>>  and find that the color is set to transparent.  Which would be find
>>>>>  except that StringMorph uses color as it's text color, not the primary
>>>>>  (i.e. background) color.  Seems to be this is incorrect.  Shouldn't
>>>>>  there be a textColor attribute used as the color to draw the text and
>>>>
>>>>  > color be used as the background color?
>>>>  >
>>>>  > Ken
>>>>  >
>>>>  >
>
>
>



More information about the Squeak-dev mailing list