Smalltalk › Squeak › Squeak - Dev

Preferences and Environments

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Colin Putney-3

Preferences and Environments

Hi all,

Here's a weird consequence of environments: since many of our preferences are now created via pragmas, and environments allows the "same" class to be loaded into more than one environment at the same time, we have the potential for a preference to have different settings in different environments.

AFAICT that should be fine, except at the GUI level, where we need to make it clear what's going on when a preference exists in more than one environment. That ought to be a project for 4.6, as it's too big to shoe-horn into 4.5.

In the meantime, what do you think? Are the problems that environment-specific preferences would cause? Is there something cool we could do with it?

Colin

Frank Shearar-3

Re: Preferences and Environments

On 9 January 2014 00:49, Colin Putney <[hidden email]> wrote:

>
> Hi all,
>
> Here's a weird consequence of environments: since many of our preferences
> are now created via pragmas, and environments allows the "same" class to be
> loaded into more than one environment at the same time, we have the
> potential for a preference to have different settings in different
> environments.
>
> AFAICT that should be fine, except at the GUI level, where we need to make
> it clear what's going on when a preference exists in more than one
> environment. That ought to be a project for 4.6, as it's too big to
> shoe-horn into 4.5.

Agreed. You have two Environments at play: that of your IDE, and that
of the code. "In the context of the Environment in which this code
runs, the preference Foo has value #localValue."

> In the meantime, what do you think? Are the problems that
> environment-specific preferences would cause? Is there something cool we
> could do with it?

My first thought is that it lets people using the wrong (*) token for
assignment - $_ - to change Scanner's preference within their
Environment, while the base/"top" Environment uses the correct token -
:=. Ditto for things that require allowing $_ in selectors, like
Xtreams.

frank

> Colin

(*) :)

Colin Putney-3

Re: Preferences and Environments

On Thu, Jan 9, 2014 at 3:20 AM, Frank Shearar <[hidden email]> wrote:

My first thought is that it lets people using the wrong (*) token for

assignment - $_ - to change Scanner's preference within their
Environment, while the base/"top" Environment uses the correct token -
:=. Ditto for things that require allowing $_ in selectors, like
Xtreams.

Oooh. That's pretty sweet, alright.

However, the way things are currently implemented, it's tricky to actually do that. We'd have to have another copy of Compiler and Scanner loaded into one environment, import it into the Xtreams environment and then override #compilerClass to return the imported Compiler in all the classes that get compiled there. Yuck.

Ugh. It looks like Pragma preferences and Environments don't mix well.

Frank Shearar-3

Re: Preferences and Environments

On 9 January 2014 16:38, Colin Putney <[hidden email]> wrote:

>
>
>
> On Thu, Jan 9, 2014 at 3:20 AM, Frank Shearar <[hidden email]>
> wrote:
>
>>
>> My first thought is that it lets people using the wrong (*) token for
>> assignment - $_ - to change Scanner's preference within their
>> Environment, while the base/"top" Environment uses the correct token -
>> :=. Ditto for things that require allowing $_ in selectors, like
>> Xtreams.
>
>
> Oooh. That's pretty sweet, alright.
>
> However, the way things are currently implemented, it's tricky to actually
> do that. We'd have to have another copy of Compiler and Scanner loaded into
> one environment, import it into the Xtreams environment and then override
> #compilerClass to return the imported Compiler in all the classes that get
> compiled there. Yuck.
>
> Ugh. It looks like Pragma preferences and Environments don't mix well.

That's true, for the moment. I'd like to at some point experiment with
having imports _import an anonymous subclass_ of something. In that
case, you'd end up with Xtreams having its own Compiler class, and the
problem would go away.

(I want to try this to see if I can make Environment-local extension methods.)

frank

Colin Putney-3

Re: Preferences and Environments

On Thu, Jan 9, 2014 at 1:06 PM, Frank Shearar <[hidden email]> wrote:

(I want to try this to see if I can make Environment-local extension methods.)

Yeah, me too, but I'd rather do it with per-environment symbol tables.

Anyway, it's probably worth special casing compilation-related preferences to be per-environment, precisely so that we can have special environments for wonky code like Xtreams. It's not hard to imagine compatibility environments for VW or Pharo.

Colin