On 9/29/16, Jakob Reschke <jakob.reschke at student.hpi.de> wrote:
> 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 at 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.

Another maybe simple use case could be to have a project specific
environment set up when you enter a project
(http://wiki.squeak.org/squeak/1020).

We now have very nicely cleaned up Project code in Squeak 5.1

1) Subclass MorphicProject --- MyMorphicProject
2) Subclass PasteUpMorph  --- MyPasteUpMorph
3) Override #initialize in MyMorphicProject and use MyPasteUpMorph
4) ... some more adaptations ..... to enter a new Environment -- how?



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