| Global Variables in imported EOL [message #891021] |
Sat, 23 June 2012 15:46  |
 Lukas Baron
Messages: 10
Registered: June 2012 |
Junior Member |
|
|
Hi,
I have two EOL Scripts A and B, A imports B, both declare global variables with var [name] : [Type] = [Value];
This means they are declared outside of an "operation {...}".
In such operations I can only access Variables of Script A. Any access to a global variable of Script B even inside of a B-operation results in an exception.
Why is this the case? Is there a workaround expect declaring each variables in A, this would not be very nice? I have multiple operations in B, which need such a global variable.
Thanks in Advance
Lukas
|
|
|
|
|
| Re: Global Variables in imported EOL [message #891269 is a reply to message #891040] |
Sun, 24 June 2012 10:08  |
Antonio Garcia-Dominguez
Messages: 227
Registered: January 2010 |
Senior Member |
|
|
We'll need to think a bit more about this. We have a bug somewhat related to your problem, though in our case it's because we might want to run "subscripts" (nested subtemplates in EGL or nested data bindings in EUnit). Still, your problem covers another usage scenario for global variables, so you might want to describe your problem here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=347367
I still think that we shouldn't switch to always executing imported EOL scripts, as that might break existing code. We'd probably need to either define a new statement which worked like "import" but ran the imported script as well. However, that means you probably wouldn't be able to run it as a standalone program (as you can now).
Alternatively, we could define a variant of the "var" statement which produced a global variable instead of a local variable, like this:
You'd need to use such a statement inside an operation ("init()" for example), import its module and then run its init() operation. It does feel a bit cumbersome, hmm.
Another option would be to allow for an optional "init" block in EOL scripts (like the "BEGIN" blocks in Perl), which would be always run before anything else, whether imported or directly executed. The rest of the code at the global scope would be run only when directly executed, though.
Something like this:
-- imported.eol
init {
var x := 0;
}
("zero is: " + x).println();
-- main.eol
import "imported.eol"; -- only defines x, does not print anything
("one is: " + ( x + 1 )).println();
What do you think? I like the third approach, though: it doesn't break anything and it feels more comfortable to use than the other two.
|
|
|
|
|
|
|
|
| Re: Global Variables in imported EOL [message #891816 is a reply to message #891582] |
Tue, 26 June 2012 02:46 |
Louis Rose
Messages: 427
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Antonio Garcia-Dominguez wrote on Mon, 25 June 2012 05:46Lukas: I'm afraid naming it as "onimport" would be slightly misleading, as we'd probably need to run it whenever it is loaded, not just when it is imported. We'd run it both when the script was run directly and when it was first imported, to avoid having to duplicate its code. I still think "init" would be better: "begin" (like in Perl) would confuse users into which code ran first (the code in the global scope, or the "begin" blocks?), and we already have "pre" annotations for the preconditions in an operation.
Perhaps pre would be a better name, as we already have pre blocks in the rule-based languages. Furthermore, this could be implemented by pulling up the implementation of pre blocks from ErlModule to EolModule.
At the moment, I think I'd be inclined to vote against adding this feature. Like Steffen, I dislike global variables, and suspect we should not be encouraging their use (nor fixing the obscure bugs that may arise from their use!)
[Updated on: Tue, 26 June 2012 02:47] Report message to a moderator |
|
|
|
| Re: Global Variables in imported EOL [message #892142 is a reply to message #892020] |
Wed, 27 June 2012 04:23 |
Antonio Garcia-Dominguez
Messages: 227
Registered: January 2010 |
Senior Member |
|
|
Dimitris: wouldn't that break code in some cases?
By now, users may have relied on EOL ignoring those bits of code, so they may have small programs for debugging at the global level in those imported scripts. They probably won't expect that code to be suddenly run in a new version.
We should either add a big warning to the next version, or ask users to explicitly tell EOL to run that code.
I'd revise your example into this:
imported.eol
----------------
pre {
var x = 0;
}
("Debugging: " + x).println();
operation recordVisit() {
x = x + 1;
return x;
}
main.eol
----------------
import "imported.eol"; // doesn't print anything (only runs the "pre" block)
recordVisit().println(); // prints 1
recordVisit().println(); // prints 2
or this (notice the switch from "import" - old behaviour - to "require" - new behaviour):
imported.eol
----------------
var x = 0;
("Debugging: " + x).println();
operation recordVisit() {
x = x + 1;
return x;
}
main.eol
----------------
require "imported.eol"; // prints "Debugging: 0"
recordVisit().println(); // prints 1
recordVisit().println(); // prints 2
We would have to deprecate "import" in favor of "require" in the second case, which would be somewhat bothersome. Also, we wouldn't be able to separate initialization from the code used to debug that EOL script.
[Updated on: Wed, 27 June 2012 04:24] Report message to a moderator |
|
|
| Re: Global Variables in imported EOL [message #892153 is a reply to message #892142] |
Wed, 27 June 2012 04:52 |
Dimitris Kolovos
Messages: 372
Registered: July 2009 |
Senior Member |
|
|
Hi Antonio,
One way or another, this won't be a completely backwards compatible change as we'll either be introducing new keywords or we'll be changing the behaviour of existing scripts :S I'll need to think more about this.
Cheers,
Dimitris
|
|
|
Powered by
FUDForum. Page generated in 0.02509 seconds
] 
Search
Help
Register
Login
Home
.