Hi all!

"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
[SNIP]
> This is to remove the wrong aspect.  It's not the globality that is
> a problem.  On the contrary, you *want* things like Smalltalk and
> Sensor and TextConstants to be global.  It's the (accidental)
> *variability* that is a problem.  So take *that* away.  Squeak already
> supports global read-only bindings (with careful rebinding by system
> code); so use that mechanism for these system globals as well.
> 
> Now, if we had 1800 global named constants (other than class names),
> then "globality" _would_ be a problem, and we'd need to partition that
> name space somehow.  But with just 12, let's focus on the right problem.
> Having 12 globally visible named constants is _not_ a problem.

I agree with Richard, globals "per se" is not a problem. We have all
"learned" the hard problems with lots of globals that are being
manipulated in different places in software, but this is not the same
thing, as Richard points out - these are things that typically don't
change.

My proposal is to:

1. Introduce a lightweight namespace solution like my package Namespaces
is. :) It just partitions all these globals into named buckets, that is
all. And the top bucket named "Smalltalk" is still there. In other
words, we get the ability to partition these globals *if we want to*,
and the developer will almost not notice - you can still type/read
"Transcript", even if it is in the namespace "Globals" (instead of in
"Smalltalk").

2. Add the &Foo mechanism in order to be able to access the binding in a
clean way. And create a specific Binding object instead of using
Association.


Going further *at this stage* doesn't seem needed nor advisable. I am
all for moving Squeak into the future, but remember Modules-3.3 :) - if
we change stuff too radically too fast - then people will not follow. So
actually *removing* the concept of global references and turning that
into a message send - well... it seems a bit brutal. :)

And note that I find the concept clean and nice, just like in Slate, but
the Squeak community is large and diverse - we need to take good care of
it.

In other words - if we intend to do a radical break with Smalltalk-80
(not counting small added things like {}-array creation or &Foo
references) we should plan for it and try to have a good
discussion/decision process for it.

For example, we could decide that 3.9 is the last "Smalltalk-80
compatible" release and that we intend to move forward in 4.0. Traits is
a good example of a thing I would like to investigate for a Squeak 4.0.

regards, Göran

PS. My view is that Squeak is NOT == Smalltalk. It just happens to be at
this moment. :) And when/if we move forward to something new then we
should of course take great care in being as backwards compatible or
easily migrateable as possible.