|Re: Global Variables in imported EOL [message #891269 is a reply to message #891040]
||Sun, 24 June 2012 14:08
| Antonio Garcia-Dominguez
Registered: January 2010
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:|
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:
var x := 0;
("zero is: " + x).println();
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 06:46
| Louis Rose
Registered: July 2009
Location: York, United Kingdom
Antonio Garcia-Dominguez wrote on Mon, 25 June 2012 05:46|
Lukas: 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 06:47]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.15031 seconds