Stephen Pair wrote:

> One of the problems this introduces is how to bind DoIts.  This is
> apparent when you try to execute some workspace code that includes a
> capitalized variable that you intend to make a Global when executed.
> You are prompted with something that says "Declare Global in Module...".
> When you select this item, you are presented with an opportunity to
> enter the module in which you'd like the global declared.  After
> selecting the default, I get a walkback saying that you "Cannot store
> into read-only bindings" (I was trying to assign to my new global).
> 
> I see a couple of problems with this:
> 
> 1. The binding is made read-only...why?

Ehm this is not a bug its a "feature". When I was halfway through the module
code the read only bindings were thrown into the stream without any warning,
and the policy I could come up with was to use them by default (as in the
nonö-modular system). I soon realized too that this was not very handy so I
invite anyone to invent a better policy. Having them not be used by default
is one attractive option.

> 2. Why present the user with a choice of modules?  It seems that if we
> want to keep the module system from being too much a burden that we
> ought to have a notion of a "current module"

Yes, but someone needs to implement it.

> with which all DoIts should
> be bound. 

No all I think. Sometimes you're in the context of a method in the debugger,
sometimes in a class on the class side of the browser. Etc.

> This would eliminate the question of which module to place
> the global.  We could deliver Squeak with a "New Changes" module already
> active, similar to the way we do with change sets.

Not quite eliminate, but provide a default value indeed. And what you
suggest seems natural, but again someone has to contribute it. (and a few
dozen other things)

Henrik