Hi Stephan,

I'm sorry for the noise.

At the time, both #at: and #getEnv: variants existed. The changes backported from the PharoLauncher were only using the getter versions of getEnv, but for Pharo I decided to implement also the setter versions. And after checking the code and its users in image, I've finally decided to go for an at:[[ifAbsent]put:] version. So I'd say that the leading **guideline** was at the end the one here in the mailing list, but also if you check the PR I've introduced a more complete and consistent API, following the one of dictionaries.

https://github.com/pharo-project/pharo/pull/1980/files

at:
at:ifAbsent:
at:ifPresent:
at:ifPresent:ifAbsent:
at:put:
removeKey:

Plus, in *nix, variants where an encoding can be specified.

I'm sorry if I've introduced some confussion.


On Wed, Jan 16, 2019 at 9:47 AM Stephan Eggermont <stephan@stack.nl> wrote:
>
> Guillermo Polito <guillermopolito@gmail.com>
> wrote:
> > Hi all,
> >
> > following the meeting we had here @Inria headquarters, I'll be backporting
> > some of the improvements we did in the launcher this last month regarding
> > the encoding of environment variables.
> >
> > I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/
> >
> > We have already studied possible alternatives with Pablo and Christophe and
> > we have some conclusions and we propose some changes:
> >
> > API Proposal for OSEnvironment
> > =========================
> >
> >
> > �� ��-
> > *at: aVariableName *
> >
> > Gets the String value of an environment variable called `aVariableName`
> > It is the system reponsibility to manage the encoding.
> > Rationale: A common denominator for all platforms providing an already
> > decoded string, because windows does not (compared to *nix systems) provide
> > a encoded byte representation of the value. Windows has instead its own
> > wide string representation.
> >
> > �� ��- *[optionally] rawAt: anEncodedVariableName*
> >
> > Gets the Byte value of an environment variable called
> > `anEncodedVariableName`.
> > It is the user responsibility to encode and decode argument and return
> > values in the encoding of this preference.
> > Rationale: Some systems may want to have the liberty to use different
> > encodings, or even to put binary data in the variables.
> >
> > �� ��- *[optionally] at: aVariableName encoding: anEncoding*
> >
> > Gets the value of an environment variable called `aVariableName` using
> > `anEncoding` to encode/decode arguments and return values.
> > Rationale: *xes could potentially use different encodings for their
> > environment variables or even use different encodings in different parts of
> > their file system.
> >
> > Other Implementation details
> > =========================
> >
> > �� ��- VM primitives returning paths Strings should be carefuly managed to
> > �� ��decode them, since they are actually C strings (so byte arrays) disguised
> > �� ��as ByteStrings.
> > �� ��- Windows requires calling the right *Wide version of the functions from
> > �� ��C, plus the correct encoding routine. This could be implemented as an FFI
> > �� ��call or by modifying the VM to do it properly instead of calling the Ascii
> > �� ��version
> >
> >
>
> What is the conclusion from this and issue 22658? See PR 2238. #getEnv: is
> public API
>
> Stephan
>
>
>


--

�� ��

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13