Smalltalk › Cincom › VisualWorks

[BUG] Duplicate ivar names in the same class

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Boris Popov, DeepCove Labs (SNN)

[BUG] Duplicate ivar names in the same class

I ran across a case where one class wouldn't load from Store due to
Unloadable Definition Error only to find out that this class' definition
included two variables with exactly the same name. You can try the
following in your own image,

Smalltalk defineClass: #Foo
superclass: #{Core.Object}
indexedType: #none
private: false
instanceVariableNames: 'var var '
classInstanceVariableNames: ''
imports: ''
category: 'My Package'

which will even ask you twice if you want to overload a variable called
'var' ;)

While overloading variables from a superclass is dangerous, but
workable, it sure seems that duplicate vars in the same class should be
off-limits as that can make for some interesting bugs I would imagine,
although to be honest I didn't have enough time to investigate the side
effects of such corruption in detail just yet.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

Reinout Heeck-2

Re: [BUG] Duplicate ivar names in the same class

I regularly see this doubled variable issue in our images, I suspect it
is one of the refactorings that does this.

I don't know for sure which one but 'push ivar up' and 'convert to
sibling' are high on my list of suspects.

R
-

Boris Popov wrote:

> I ran across a case where one class wouldn't load from Store due to
> Unloadable Definition Error only to find out that this class' definition
> included two variables with exactly the same name. You can try the
> following in your own image,
>
> Smalltalk defineClass: #Foo
> superclass: #{Core.Object}
> indexedType: #none
> private: false
> instanceVariableNames: 'var var '
> classInstanceVariableNames: ''
> imports: ''
> category: 'My Package'
>
> which will even ask you twice if you want to overload a variable called
> 'var' ;)
>
> While overloading variables from a superclass is dangerous, but
> workable, it sure seems that duplicate vars in the same class should be
> off-limits as that can make for some interesting bugs I would imagine,
> although to be honest I didn't have enough time to investigate the side
> effects of such corruption in detail just yet.
>
> Cheers!
>
> -Boris
>

Boris Popov, DeepCove Labs (SNN)

Re: [BUG] Duplicate ivar names in the same class

Reinout Heeck wrote:
>
> I regularly see this doubled variable issue in our images, I suspect
> it is one of the refactorings that does this.
>
> I don't know for sure which one but 'push ivar up' and 'convert to
> sibling' are high on my list of suspects.

Right, except that if compiler would reject such violations at the low
level, we'd know pretty soon of all the evil scenarios that cause the
problem in the first place. After all, if Store considers this invalid,
why doesn't the base system?

Cheers!

-Boris

>
>
> R
> -
>
>
>
> Boris Popov wrote:
>> I ran across a case where one class wouldn't load from Store due to
>> Unloadable Definition Error only to find out that this class'
>> definition included two variables with exactly the same name. You can
>> try the following in your own image,
>>
>> Smalltalk defineClass: #Foo
>> superclass: #{Core.Object}
>> indexedType: #none
>> private: false
>> instanceVariableNames: 'var var '
>> classInstanceVariableNames: ''
>> imports: ''
>> category: 'My Package'
>>
>> which will even ask you twice if you want to overload a variable
>> called 'var' ;)
>>
>> While overloading variables from a superclass is dangerous, but
>> workable, it sure seems that duplicate vars in the same class should
>> be off-limits as that can make for some interesting bugs I would
>> imagine, although to be honest I didn't have enough time to
>> investigate the side effects of such corruption in detail just yet.
>>
>> Cheers!
>>
>> -Boris
>>

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

Charles A. Monteiro-2

Re: [BUG] Duplicate ivar names in the same class

interesting,

I just created a class called TestFoo with two instVars: foo and foo,
I asked the class to generate accessors which created #foo and #foo:

I then instantiated a TestFoo and sent it #foo: 'hello'

result:

assignment apparently fails i.e. the inspector shows both instVars as nil,
but wait if one uses the accessor #foo on said object one gets 'hello',
wonderful, all of those who insist on using accessors for everything are
correct after all :), but wait I then wrote a method:

goodNight

^ foo , ' is too far away['

and told my TestFoo friend #goodNight and it replied: 'hello is too far
away',
ah so apparently trippy does not show the value but the value is there, as
a matter of fact if one opens trippy on one of these guys and finds a
method i.e. like #goodNight above and selects and inspects the token "foo"
one will get 'hello'.

I then put a breakpoint in #goodNight , the debugger shows nil for the
instVar slots but again highlighting and inspecting "foo" will work.

further more if I do the following:

myTestFooInstance instVarAt: 1 -- I get nothing, nada, nil
myTestFooInstance instVarAt: 2 -- I get 'hello'

btw, TestFoo is subclassed from Object.

After all of this I decided on yet one more final experiment:

I then created another class called TestFooAgain with one instVar: foo
created accessors
instantiated it and sent #foo: 'hello', etc

result:

everything works , thank god :)

-Charles

On Thu, 19 Jan 2006 12:09:34 -0500, Boris Popov <[hidden email]>
wrote:

> Reinout Heeck wrote:
>>
>> I regularly see this doubled variable issue in our images, I suspect it
>> is one of the refactorings that does this.
>>
>> I don't know for sure which one but 'push ivar up' and 'convert to
>> sibling' are high on my list of suspects.
>
> Right, except that if compiler would reject such violations at the low
> level, we'd know pretty soon of all the evil scenarios that cause the
> problem in the first place. After all, if Store considers this invalid,
> why doesn't the base system?
>
> Cheers!
>
> -Boris
>
>>
>>
>> R
>> -
>>
>>
>>
>> Boris Popov wrote:
>>> I ran across a case where one class wouldn't load from Store due to
>>> Unloadable Definition Error only to find out that this class'
>>> definition included two variables with exactly the same name. You can
>>> try the following in your own image,
>>>
>>> Smalltalk defineClass: #Foo
>>> superclass: #{Core.Object}
>>> indexedType: #none
>>> private: false
>>> instanceVariableNames: 'var var '
>>> classInstanceVariableNames: ''
>>> imports: ''
>>> category: 'My Package'
>>>
>>> which will even ask you twice if you want to overload a variable
>>> called 'var' ;)
>>>
>>> While overloading variables from a superclass is dangerous, but
>>> workable, it sure seems that duplicate vars in the same class should
>>> be off-limits as that can make for some interesting bugs I would
>>> imagine, although to be honest I didn't have enough time to
>>> investigate the side effects of such corruption in detail just yet.
>>>
>>> Cheers!
>>>
>>> -Boris
>>>
>
>
> -Boris
>

--
Charles A. Monteiro