[BUG]UndefinedObject(Object)>>error:
Ingo Hohmann
uysl0l402 at sneakemail.com
Thu Oct 16 19:26:05 UTC 2003
Hi Andreas,
Andreas Raab wrote:
>>In all other scenarios, the shadowing is helpful.
<...>
> However, if you talk about exchanging code with others, then you've got to
> be aware that more eyeballs will look at your code - and if one of those
> sees a shadowed global it is Very Unlikely that this person will understand
> what this object is. Your recent message was a great example in this regard
> - I am sure _you_ got exactly what you wanted but poor me, trying to
> understand what I was seeing, was utterly confused.
>
> The system should therefore prevent you from introducing those shadowed
> globals even "if you get what you want". In more cases than not I would
> presume that the shadowing is purely accidental, simply introduced because
> you didn't even know that the global existed.
>
> So here's my question for you: Given the option, wouldn't you rather use a
> variable name that does not shadow a global than using one that does? And if
> the answer is "yes", then what's your argument against the system enforcing
> it?
OK, you get a shiny new package from squeakmap, but suddenly your system
complains "Sorry, you have a Global that'll be shadowed by a class var in
this package, please rename either one, otherwise I won't file in this
package, bye" - How many people will do the renaming?
Or, "Hi this is your package manager, there's a class var in this package,
that'll shadow a global, normally I wouldn't allow this, but as this is a
file in, do as you like, bye". Now you've got the same shadowing you are
forced to avoid in your own code, _but_ in code from someone else you know
even less, and you'll most surely forget about it, 'cos, "shadowing can't
happen".
Well, now you are a seasoned smalltalker, so you renamed the offending
class var. Some time later you find an error in the package, and send a
patch to the package maintainer, with the remark: "Oh, and btw, I had to
rename YourClass Xyz, I have a global of the same name in my image, and
wasn't able to save otherwise." That's exactly what you need to promote
packages, ain't it? ;-)
At the end of the day, what _I_ would like to have are proper and
documented shadowing rules, _which people are aware of_. (After all, there
are a lot of languages / smalltalks out there, which somehow seem to cope
with it).
Maybe add a visual clue to the listing of a method that access a variable
which shadows another var. That's the beauty of having everything in the
same image.
Well, just my 0.02 Euro.
Kind regards,
Ingo
More information about the Squeak-dev
mailing list
|