On ven 23 novembre 2007, Melchior FRANZ wrote:
> Most people seem to think that "var" in Nasal is a kind of
> redundant decoration, and really just noise. It isn't.
> In fact, I consider Nasal code *not* using it broken.
>
>
> "var" makes a variable guaranteed to be local. And note that
> functions assigned to variables are no exception! If you write
> code without using "var" on variables, then you risk (often
> hard to debug) breakage at a later time. Consider this code
> in one of your scripts:
>
> output = func(v) { # missing "var"
> state = getprop("/sim/foo/state"); # missing "var"
> do_something(state, v);
> }
>
>
> where neither "output" nor "state" have been declared to
> be a local variable using "var" in this file. Everything will
> work fine. For a while. Until someone creates a file
> $FG_ROOT/Nasal/state.nas or $FG_ROOT/Nasal/output.nas.
> Then your "output" and "state" will no longer create
> a safe variable, but they'll overwrite the global namespaces
> that these files meant to create. You can try this with these
> examples:
>
>
> props = func { # missing "var"
> print("I'm props. And I just wiped the whole props namespace.");
> }
>
>
> Or with this:
>
>
> foo = func { # missing "var"
> props = " :-P "; # missing "var"
> }
> ...
> foo();
>
>
> After this code was run, all props methods will stop working,
> as the props namespace containing all the important stuff was
> replaced by cheesy, thought to be local stuff.
>
> Note, again, that variables set to hold a function object are
> no exception. They should use the "var" keyword as well:
>
> var foo = func {}
>
>
> But there's another reason why "var" should be used consequently,
> even if a variable is safe enough from later side effects, because
> it's called "bo105_livery" or something. The "var" keyword makes
> reading code for others (and for the author after some time) easier,
> as it makes clear: "this variable starts its life *HERE*". No need
> to search around to see whether assigning a value to it means
> something to other code outside or not. Also, with an editor
> offering proper syntax highlighting reading such code is actually
> easier, despite the "noise".
>
> But why then does some code still not use "var", even code written
> by Andy? Because the keyword didn't exist from the beginning. It was
> added after I had run into weird error messages when starting with
> the bo105. It took me a while to find out that a variable "state"
> had nasty and unexpected side effects on the $FG_ROOT/Nasal/state.nas
> script. And now you know why this script is now known as "ac_state.nas".
>
> m.
>
>
Thanks,
I will have a lot of updates to do :(
Regards
--
Gérard
http://pagesperso-orange.fr/GRTux/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
