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@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