About removing global variables

Jecel Assumpcao Jr jecel at merlintec.com
Mon Nov 29 12:58:14 UTC 2004


lex wrote on Sun, 28 Nov 2004 12:32:30 -0400
> It does not violate POLA in Squeak's case, because the LA is simply very
> large.  Squeak is a late-bound computer authoring system,

Exactly: "system" and not language.

> and it is a
> *feature* that you can type "Display" to access the low-level bitmap,
> "Sensor" to talk to the mouse, and "Smalltalk" to talk to the system
> itself.

True.

> You are supposed to be able to read in audio and, in response,
> change the globals table and recompile classes.  Yes it's weird, but
> that's the point.  We don't know what future designers will want.

You lost me in the "read in audio" part. Do you mean a "voice fileIn"
sort of thing in some future version?

> Thus, if you were to implement Squeak in a language without global
> variables, what you'd do is create one scope that has all of Squeak's
> current globals, and then do everything inside that scope.  All you'd do
> is replace global variables, with practically global variables.

Right, so let's think about the *system* thing again.

Imagine something very like Squeak but without any globals at all. But
somehow I am able to create an instance of some class I have written and
then invoke an inspector on it. On the other side of the screen I can
see a window/icon/whatever that represents the mouse input (previously
known as the global Sensor). What if I can drag-n-drop that into one of
the instance variables in the open inspector? Now my object instance has
access to the mouse, but not to the display - the least authority it
needs to do its job.

I, as the all powerful programmer and the environment as my proxy do
have lots and lots of authority. I don't see why I should have to give
it all to every single object in the system.

> But before people go crazy, yes I think it is possible to make an
> authoring system where the least authorities aren't so large.  In fact,
> I agree that such an authoring system would be marevelous to have.  It's
> just a completely different system than Squeak.  Squeak is an
> environment for building its own successor!  To achieve that goal,
> Squeak should allow fast iteration of design ideas.  This fast iteration
> is incompatible with chopping authority into little bits.

That is not how it looks to me.

> Let's plan that, if and when people do build secure authoring
> environments similar to Squeak of today, we still continue to have
> something highly maleable like the current Squeak.  Speed of iteration
> matters, and is one of Squeak's biggest selling points.  Squeak has lots
> of goodies, and it also has lots of flexibility for doing whatever crazy
> thing you can dream up.  This is a rare and important combination, and
> we should be careful to hang on to it.

Good plan, but once again I see no relation between making things
simpler and stricter at the language level and slowing things down or
making them less flexible for the programmers.

> Finally, if we had to choose just one system, for some reason, I would
> vote for the maleable one instead of the secure one.  It is more
> important to build the next Great Thing, than to make a better Current
> Thing.

Think of SUnit tests and eXtreme Programming. In theory, the tests get
in the way of changes but in practice they are a powerful help in doing
radical refactoring since otherwise you are always too afraid stuff will
break without you noticing it to ever do serious changes.

My opinion is that a proper factoring the system that would make it much
more secure will have similar advantages in terms of maleability.
Intentions will be clearer and you can be more confident that any
problems with your changes will have instant consequences and will be
easy to fix.

-- Jecel



More information about the Squeak-dev mailing list