[BUG]UndefinedObject(Object)>>error:

ducasse ducasse at iam.unibe.ch
Mon Oct 13 19:29:55 UTC 2003


hi andreas

originally I was not interested by the thread (for other personal 
reasons (people that attended esug know why)). But I have the 
impression that if the interpretation of a classVariable is only 
visible inside the class and class of the class (plus children) then 
peter is right.

A classVariable should not be touched if you define a class that by 
accident as the same name else
all your code can break and you lose the locality of the definition. 
Imagine in presence of package without namespace.
The current semantics makes the following:
	- I checked while defining my package that there is no class with name 
X and I then use my classVariable X
	- I published it on Squeak map (perfect sunny day today)
	- then I load another package that by accident define a class or 
another classVariable with the same name
	and my code break (a black day where sleeping would have been better).

Is it really that that you are implying? I ask because I'm not sure, I 
reread twice the example because this is obvious
that this is breaking all the basic rules of locality in class 
definition. You surprised me. (I was originally thinking that
peter was making noise for nothing).


I added the kcp mailing-list because this is cool bug (even if peter 
defended it).

Stef



On Lundi, oct 13, 2003, at 21:06 Europe/Zurich, Andreas Raab wrote:

> Hi Ned,
>
>> There are two things named 'Bar': the global class, and the Foo class
>> variable.
>>
>> In Foo class, returnBar returns the class variable Bar.
>>
>> In FooSub class (which is a subclass of Foo), returnBar
>> returns the global Bar, rather than the Foo class variable.
>
> Thanks - if that isn't making Tim's point then nothing is ;-) I pasted 
> the
> code, run it, looked at it in the browser and was immediately 
> convinced that
> the result is entirely correct. Obviously, if you look at 
> FooSub[class] and
> have Bar right next to it in the browser you wouldn't possibly guess 
> that
> FooBase may have a class variable that shadows Bar.
>
> Boy, what a mess. This should be prevented At All Costs (tm).
>
> Cheers,
>   - Andreas
>

>
> Execute the script below in a workspace in a virgin Squeak
> 3.6 image to
> see the error.
>
> ----------------
> Object
> 	subclass: #FooBase
> 	instanceVariableNames: ''
> 	classVariableNames: 'Bar'
> 	poolDictionaries: ''
> 	category: 'Scope-Examples'
> .
> (Smalltalk at: #FooBase)
> 	subclass: #FooSub
> 	instanceVariableNames: ''
> 	classVariableNames: ''
> 	poolDictionaries: ''
> 	category: 'Scope-Examples'
> .
> Object
> 	subclass: #Bar
> 	instanceVariableNames: ''
> 	classVariableNames: ''
> 	poolDictionaries: ''
> 	category: 'Scope-Examples'
> .
> (Smalltalk at: #FooBase) class compile:
> 'returnBar
>
> ^Bar'
> .
> (Smalltalk at: #FooBase) returnBar == nil
> 	ifFalse: [nil error: 'FooBase: should be nil']
> .
> (Smalltalk at: #FooSub) class compile:
> 'returnBar
>
> ^Bar'
> .
> (Smalltalk at: #FooSub) returnBar == nil
> 	ifFalse: [nil error: 'FooSub: should be nil']
> ----------------

>
>



More information about the Squeak-dev mailing list