> On 12 Jul 2017, at 09:09, Marcus Denker <marcus.den...@inria.fr> wrote:
>
>
>> On 12 Jul 2017, at 08:54, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>>
>> Yes, but these are all inside the method editor.
>>
>> I wanted to start with
>>
>> (Motivation fromString: 'foo') sayIt.
>>
>> in a playground/workspace.
>
> in the workspace it creates a variable (with value nil)… so it treats
> upper-case
> unknown vars the same as lower case.
>
> I think it might make sense to have for upper case instead the menu that asks
> what to do (it could there have a “add binding to workspace” entry for the
> current
> way, too)
>
for the #asClass case it is more complex.
The compiler knows two modes:
“Interactive” and not. So if there is a undeclared var, it will in interactive
mode ask the user what to do, but when compiling non-interactively it
will just add the var to Undeclared (with a nil value) and compile a binding
to that.
Now #asClass happens not at compile-time, but at runtime. The compiler can
not do anything (it’s just a message send), and at runtime we do *not* model
“interactive use” vs. not.
Now if you look at Denis enhancement of the test execution, there is now
CurrentExecutionEnvironment value
which allows us at runtime to check if we run a test (and which). Now
we could extend that and model “interactive use” vs. “non-interactive” in
addition.
Then code like #asClass could ask the user in interactive mode to create
a non-existing class.
But the question is if we would want that…
(I like the idea of modelling interactive vs. not using the execution
environment, though).
Marcus
