On 12 Jul 2017, at 09:09, Marcus Denker <marcus.denker@inria.fr> wrote:
On 12 Jul 2017, at 08:54, Sven Van Caekenberghe <sven@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