I just wanted to reaffirm that Melchior's message about use of "var" in
nasal code is a very important one ... important enough to top post and
re-quote the whole thing below :-) and encourage everyone to read it again!
If anyone out there is doing aircraft design or involved in doing any nasal
scripting at all, they really need to read through this message and
understand it. If it's not clear to you, print it out and read it later
with a fresh head. (It's well written, but technical, so you need to read
it with patience and care.) If something is still not clear, please ask
questions!
On Nov 23, 2007 7:15 AM, Melchior FRANZ <[EMAIL PROTECTED]> 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.
>
> -------------------------------------------------------------------------
> 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
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
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
