Hi Nicolas,
First, thank you for answering me in the other thread.
2016-09-28 23:02 GMT+02:00 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
Without clear goals or vision, fixing could essentially mean "let Environment be transparent", that is let it remain a promise, a potential, whithout too many side effects... Not exactly YAGNI, just a bit of over-engineered nice piece of code that might serve later. OK this sounds like a mandatory first step.
I don't quite get what you mean by transparent, other than fixing it and enhancing the documentation to shed some light on what it is, why it is there and how to use it.
But then, what feature are we after? I have read bootstrapping, sandboxing, letting concurrent packages and/or versions co-exist, stop prefixing class names with pseudo namespace... So environment are about reducing global variable scope.
For me, the essential decisions are in these questions:
- how will environments and source-code-management interfere?
- how are we going to specify reproducible artifacts (images)?
Are we going to use environment "statically" like in VW, just like namespaces are in many languages? That somehow means that the SCM will have to be environment aware.
Or are we going to transfer this responsibility at a higher level, like Metacello for example? In this later case, we have greater flexibility, but assembling an image means telling which package is installed into which environment, then which import are necessary for each environment.
It depends on whether you look at Environments as a developer's tool (like, e. g., Java packages) or an operator's/administrator's tool (like, e. g., Docker containers, maybe). In this discrimination developers can also be operators while they gather the dependencies for their projects, for example.
Treating them as an operator's tool, I could imagine to create a new environment for every "Squeak app" you want to deploy in a production image. Installing that app via Metacello or the Squeak Map could (optionally?) create such an environment, isolating its dependencies (and their particular versions) from other apps in that image. Alternatively, you could install that app or library package into an existing environment that you must specify then. But I do not consider myself an operator, so I might be off conventional paths here...
Another thing I have in mind is running a new test case against many older versions of a package (and its dependencies?) to find out which version introduced a regression, without changing the "main" environment each time when another version is checked out. Imagine you would want to do this with the Kernel or Collections package. I would want "throwaway" environments for this.
My current naive use case is to hide from a Pharo package that I want to get going in Squeak the fact that in Pharo some classes have been renamed. I just want to make the older Squeak classes available under their changed names, without really renaming the classes themselves and without doing a big search&replace in the client package. This is probably bound to fail, because the interface has probably changed as well, but a generalization of this would be compatibility-, adapter- or emulation environments.
But it's even more complex than that, because the way we create classes: by subclassing another class. So we don't need one environment, we need at least two, one source environment for picking the super class, one destination environment for hosting the subclass. Hmm, the metacello configuration is going to be verbose... OK, OK, but how would we designate an environment in the configuration, is it by name in a sort of Environment registry?
Currently, Environments can be retrieved by name, or you have a reference to an Environment object (and treat it as anonymous). In the operations mindframe from above, I would not want a Metacello baseline or whatever to specify its environments. This configuration would only belong to the particular image you want to build. You could still put this configuration as a script into another package, of course...
On the other hand, if packages started to abandon class name prefixes, being "agnostic" to environments in your package might not be feasible in some cases, when you have to do renames to resolve naming conflicts.
I look forward to hearing other opinions.
All this is strongly related to Newspeak mechanisms for contructing a module, http://bracha.org/newspeak-modules.pdf. Newspeak was conceived with solid foundations. Can we reach a solid design by small iterations? Will we converge to the same economy of concepts? I just wonder, or should I say wander?
That's very interesting. So who has a vision? No urge to asnwer this, let's rather make environment transparent ;)
Nicolas
Best regards, Jakob