same-named class and global vars

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.

  http://bugs.impara.de/view.php?id=5905

-Lex

<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

I'd like it better if the filein code prompted the user to rename the  
class variable to resolve the conflict.

On Feb 1, 2007, at 12:27 PM, Lex Spoon wrote:

Maybe this can work for a single conflict.
However the reasons for I do not agree on that are:
- I am not aware of the details of the code I am filing in
- I would not stand being asked for each and every conflict if there are
many

What if the class var is already installed ?
Do you rename the class you are loading or the already installed class var?
Maybe there are ten classes having a class var #Time. You gonna ask 10
times?
Then when you unload the conflicting package, you have messed already
installed code... Bad.

The scope are nested, there is a precedence rule, inner scope first,
outer last, and if imported class has a class var Time, it for sure
won't use the global class Time.

If you modify code interactively, simply warn the user of potential problem.

Smalltalk should be less pedantic than i am, don't you think so?

Nicolas


Todd Blanchard a écrit :
> I'd like it better if the filein code prompted the user to rename the
> class variable to resolve the conflict.
>
> On Feb 1, 2007, at 12:27 PM, Lex Spoon wrote:
>