>> I don't like the idea of CurrentEnvironment at all. IMO global state
>> stinks.
>> It would mean that a lotta behavior would change by simply switching one
>> shared variable...
>> I see it more like a not so clever workaround to make tools still work in
>> presence of environments with minimal changes.
>
>
> Global state does indeed stink, which is why Environments is so nice,
> because "global" isn't global anymore.

This deserves some qualification.  Its true that writable globals
stink, you never know what state its going to be in, and updating it
introduces contention, etc.  However, Class names don't suddenly point
to a different class object within the context of a running
application, and no one ever replaces Smalltalk with a new instance.
These globals are just "there" -- read-only bindings which don't
suffer the stinky issues associated with writable globals.

I'm glad Nicolas started the other thread asking "what's it for?"  To
me, that's the most important question -- is there something actually
truly useful gained in exchange for complicating the language and
tools?  Is it only about everyone being able to have elegant,
prefix-less class names all loaded into one image?  Most of the
use-cases mentioned in this and the other threads were just "cool ways
to handle a one-off problem."

For the real world, we have been wanting smaller, more modular images.
The conditions of having less code and responsibility in those smaller
images bodes them less likely to benefit from Environments.  Multiple
small images passing messages over the network lets those Smalltalk
applications run on multiple processor cores, compared to one
monolithic image with all the code loaded and disambiguated via a
hierarchy of Environment imports/exports and running on just one
process core.

In 15 years, I think I've had just one name collision between classes
of different packages (neither of which used prefixes).  I think I
simply renamed one of them.  Dynamic system.  With Environments, I
would still have had to write some code to do various
imports/exports/renames, etc.. and so it doesn't actually save me any
development effort.  I guess it boils down to letting me keep pretty,
but ambiguous, names in the code.  But, I actually prefer prefixes...

Not trying to be a party pooper, but complexity is commonplace,
simplicity is rare.  If we still have a simple system, we should value
that aspect and try to keep it that way.  At least _optionally_...

Best,
  Chris