same-named class and global vars

Alan Lovejoy squeak-dev.sourcery at forum-mail.net
Fri Feb 2 07:46:39 UTC 2007



<Lex Spoon>
"I am trying to finalize a packages distribution for 3.9, and I discovered a
sad problem: SmallDEVS and Exupery cannot be loaded at the same time.  The
reason is a sad one: SmallDEVS has a class named Timer, and Exupery has a
class variable named Timer.

If the system were to allow loading these two packages, they would almost
certainly coexist just fine.  It is un-Squeaklike to be so worried about a
potential error (accessing the wrong variable), that we immediate cause a
total failure (rejection by the compiler).

Can we at least allow this situation at *load* time, even if most developers
are against allowing it in the IDE ?  At load time it is too late, and you
may as well go for it IMHO.  It would also be consistent with our creating
fresh global variables in "Undefined", as a way to work around semi-broken
code modules."
</Lex Spoon>

Class variable definitins should override global variable definitions.  And
that's how Smalltalk-80 originally worked (or at least, that's how it worked
when I first started using it in 1985.)  That's how most Smalltalk
implementations work today.  The weight of precedent and general practice
(sometimes referred to as "respect for prior art") argue strongly and
compellingly that Lex is absolutely correct.

I would also argue that a situation where the independendent definition of
new global variables is able to make the code of a class in some optional
module invalid is a stunning and unforgiveable violation of the principle of
encapsulation, and should be jettisoned ASAP on that basis alone.  Squeak
will never solve the modularization/deployment issues it now suffers from if
ill-considered design choices such as this global/class-var name clash error
are allowed to stand.

--Alan





More information about the Squeak-dev mailing list