I suppose nobody of us wants throw everything over and force
Environments onto it. All of this is about opportunities that were
available if Environments could actually be used and operated
intuitively, right? I, too, think that you should not have to care
about Environments if you do not want to. Though, it might be
neccessary or advantageous in some uncommon cases, some of which we
have collected already.

Some code, however, like the loading facilities of Monticello,
currently seem to not play very well together with Environments
(because of the access to the Smalltalk dictionary, how that is
implemented in Environment, and the dynamic binding issue). But if you
cannot load/install something into an Environment and if there are no
(additional) tools to put code into an Environment and then run it,
then how are you supposed to make use of the feature?

Now that I formulated it that way, I think somebody claimed to already
use Environments for something at some point in another, older
discussion. I would like to know how they did it, given Environments'
current state.

If you only refer to the dynamic Environment issue with your comment
about added complexity, an alternate solution would possibly be to add
explicit environment parameters to all facilities that would need them
and that do not have them yet (thinking of Monticello again). But that
seems even more invasive to me and it bloats interfaces if you also
want to keep the existing environment-agnostic interface, which we
certainly want to do.

Kind regards,
Jakob

2016-09-30 23:36 GMT+02:00 Chris Muller <asqueaker at gmail.com>:
>>> 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
>