Home » Modeling » Epsilon » Global Variables in imported EOL(global var-clause ignored?)
Global Variables in imported EOL [message #891021] |
Sat, 23 June 2012 15:46  |
Eclipse User |
|
|
|
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   |
Eclipse User |
|
|
|
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   |
Eclipse User |
|
|
|
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] by Moderator
|
|
| | |
Re: Global Variables in imported EOL [message #892153 is a reply to message #892142] |
Wed, 27 June 2012 04:52  |
Eclipse User |
|
|
|
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
|
|
|
Goto Forum:
Current Time: Tue Jul 22 19:24:21 EDT 2025
Powered by FUDForum. Page generated in 0.34944 seconds
|