[FIX] ClassVarsFix-petervr (was: Sharedvariablesbinding/lookupbug)

Tim Rowledge tim at sumeru.stanford.edu
Mon Oct 13 04:12:40 UTC 2003


> Tim, let me get this straight: Before you define or rename a class you
> always check if any existing class has a class variable, or any existing
> pool dictionary has a pool variable with the name you are planning to use
> for your class. Correct?
Not quite; first, if I were able to actually live up to every piece of
good practise that I know of or have attempted to teach then you'd be
able to read by the glow of my halo :-)

Secondly, I think you've read a little more globalness into my words
than I intended. Worrying about class variables in a disjoint hierarchy
(and yes, one could point out that when all classes descend from Object
that that is a dodgy concept) is probably going too far. PoolDicts are
such a pain that I get a headache even saying the word let alone
thinking about them. But basically, yes I try to make sure that there
is minimal cognitive clash in the code. Do I fail? Oh boy, bigtime.
Won't stop my trying and hoping that I can persuade others.

> You are correct, I don't need to lecture you on how Smalltalk works. It also
> goes without saying that since you have been 'making it professionally for
> twenty years', your judgments about it are much more valuable than whatever
> opinion I might have about it.
Excessive humility is at least as big a sin as excessive pride. Say
three Hail Alans and write out the morphic hierarchy 100 times in
expiation.

> 
> > > > Even worse, the time-order of compiling
[snip]
> 
> I'm not sure I see what you're getting at, since this does not support your
> case at all. If both methods are in the same class, both occurrences of Foo
> refer to the class variable. What is your point?
If the adding of the class variable results in the method that referred
to the global Foo being changed 'under the covers' then the original
intent of the writer has been subverted. If the original method is not
changed then the association placed in the literal frame _looks_ like
it refers to the class var - same textual name for the key - but is a
quite different object to the association referred to by the other
method.  

This isn't something I worry about enough to be motivated to debate to
death let alone to actually write code for. I have _way_ too many other
things to handle. I've had my little rant and that's sufficient for
now. Any time I catch code commiting this little sin I'll complain and
hope to persuade someone to accept a change.


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: PRM: PRint Money



More information about the Squeak-dev mailing list