[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
|