4,400
edits
Nasal Namespaces in-depth: Difference between revisions
Jump to navigation
Jump to search
m
Link to special directory articles
No edit summary |
m (Link to special directory articles) |
||
| Line 8: | Line 8: | ||
== Namespaces in FlightGear == | == Namespaces in FlightGear == | ||
If you look at the graph on the right, you will see a representation of how namespaces look in FlightGear. At the top there is the global namespace, called "globals", and various other namespaces branch down from there. On the left there are the namespaces created from the modules in $FG_ROOT and $FG_HOME, e.g. controls.nas makes the namespace "controls". In the center there are the ‘special’ namespaces, for the joystick(s) and the keyboard (there is only support for one keyboard hence only one namespace). Everything found in the joystick or keyboard files are executed in their respective namespaces – the <nasal><script> section at the top and all of the <binding>s. Next are the GUI dialogs, which have "__dialog:" as a prefix in front of the dialog's name (which I believe comes from the filename). | If you look at the graph on the right, you will see a representation of how namespaces look in FlightGear. At the top there is the global namespace, called "globals", and various other namespaces branch down from there. On the left there are the namespaces created from the modules in [[$FG_ROOT]] and [[$FG_HOME]], e.g. controls.nas makes the namespace "controls". In the center there are the ‘special’ namespaces, for the joystick(s) and the keyboard (there is only support for one keyboard hence only one namespace). Everything found in the joystick or keyboard files are executed in their respective namespaces – the <nasal><script> section at the top and all of the <binding>s. Next are the GUI dialogs, which have "__dialog:" as a prefix in front of the dialog's name (which I believe comes from the filename). | ||
As you look at the tree structure, notice how one can move around on it. One can go up to a more global namespace or one can go down to a sub-namespace of the current namespace. Each "leaf" or "branch" only has one parent (e.g. the only thing above "controls" is "globals") while they can contain multiple children (the reverse of the previous comment applies, globals contains not only controls but io, gui, etc., as well). | As you look at the tree structure, notice how one can move around on it. One can go up to a more global namespace or one can go down to a sub-namespace of the current namespace. Each "leaf" or "branch" only has one parent (e.g. the only thing above "controls" is "globals") while they can contain multiple children (the reverse of the previous comment applies, globals contains not only controls but io, gui, etc., as well). | ||
| Line 23: | Line 23: | ||
== Namespaces in Functions == | == Namespaces in Functions == | ||
Every single namespace in Nasal is just a hash. The most common namespaces are the ones inside the Nasal modules ($FG_ROOT/Nasal) and the globals namespace, these are probably the easiest to understand. In fact everything needs to run in namespace, and that includes joystick bindings. But less understood is the fact that every function creates it's own anonymous namespace to run in, e.g. gearDown in controls.nas has its own namespace that it runs in. These namespaces are not assigned a name like the controls namespace is. Instead, they simply exist as a part of the function and can only be fetched using closure() level 0. Anyways, this has the obvious implications that any variables created inside the function stay in that function (and get destroyed after the function returns). A function can also modify variables in the outer scope, either by leaving out the 'var' qualifier or by using caller(). Local variables cannot be accessed from the outer scope, as far as I know, though I am not sure what closure returns for such things. This notion of functions creating new namespaces has some interesting implications, see "Advanced namespace hacking: security wrappers". | Every single namespace in Nasal is just a hash. The most common namespaces are the ones inside the Nasal modules ([[$FG_ROOT]]/Nasal) and the globals namespace, these are probably the easiest to understand. In fact everything needs to run in namespace, and that includes joystick bindings. But less understood is the fact that every function creates it's own anonymous namespace to run in, e.g. gearDown in controls.nas has its own namespace that it runs in. These namespaces are not assigned a name like the controls namespace is. Instead, they simply exist as a part of the function and can only be fetched using closure() level 0. Anyways, this has the obvious implications that any variables created inside the function stay in that function (and get destroyed after the function returns). A function can also modify variables in the outer scope, either by leaving out the 'var' qualifier or by using caller(). Local variables cannot be accessed from the outer scope, as far as I know, though I am not sure what closure returns for such things. This notion of functions creating new namespaces has some interesting implications, see "Advanced namespace hacking: security wrappers". | ||
== Dealing with Different Namespaces at Once == | == Dealing with Different Namespaces at Once == | ||