David Megginson wrote:
> Originally, I defined actions using XML mainly because we didn't have
> a scripting language, but ideally, we should share up the labour like
> this:
>
> XML = declarative
> NASAL = imperative
Completely agree. Although it should be pointed out that there's
significant gray area between the two extremes. Some of the existing
commands (like property-adjust, with its handy wrap and clamp options)
are simpler than the equivalent Nasal code for typical usages.
Likewise, sometimes declaring your data in Nasal can save a lot of
work interpreting that data on the C++ side. The mouse.nas sample was
a good example of this. The whole idea of "mouse mode" cooked down to
a literal object definition, where the methods were handlers for each
event type. And the list of modes was simply a literal list dropped
right there in the file. (Again, there's no point in replacing the
mouse code, but if we were doing it from scratch...)
But here's a question on a related subject. How do we handle
declaration of Nasal code? The ability to write inline handlers is
great, but limited to small functions. The ability to drop module
files into the Nasal directory is great too, for globally useful
code.
But sometimes you have non-trivial code that is nonetheless
context-specific. The obvious example (as Melchior pointed out to me
this morning) is per-aircraft scripts. We don't to have to drop a
c172.nas file into the global namespace if we're flying a bo105. My
answer to this issue this morning was this:
> I'm thinking about a property-space configuration, where you could do
> something like:
>
> <nasal>
> <import>
> <module-name>bo105</module-name>
>
> <source-file>bo105.nas</source-file> <!-- Either a file -->
>
> <!-- Or inline source code: -->
>
> <script><[CDATA[
> ...nasal source code...
> ]]></script>
>
> </import>
> </nasal>
>
> And the Nasal subsystem would then step through all the
> "/nasal/import" entries it found in the property tree and load the
> appropriate modules at initialization.
But unfortunately that doesn't work, because multiple definitions of
the same property (/nasal/import, this case) from different files
overwrite each other. I had been under the impression that they
defined new indices ("/nasal/import[1]", etc...), but that only works
from the same file.
The requirement is basically that arbitrary PropertyList XML files be
able to define Nasal code that will be found by the FGNasalSys object
at initialization. I can see a few ways to do this, all ugly to
differing degrees:
+ Hack at the SimGear property parser to understand the FlightGear (!)
nasal subsystem and invoke the (Nasal) parser at (XML) parse time.
No. :)
+ Hack at the property parser to support the "add index" behavior
across files. Less ugly, but this might (probably will) break
existing usage that expects to override the global property instead.
+ Write initialization code to walk through the entire property tree
looking for "nasal-import" nodes. This isn't so bad to implement,
and is easy to understand, but walking the tree just seems icky.
It's also a mild encapsulation violation, since sub-trees might want
control over their own nodes' interpretation.
+ Use a "/nasal/unique-name" convention instead. Then the
FGNasalSys::init() method simply iterates over all the children of
/nasal, instead of all the indices of /nasal/import. The only trick
here is coming up with a truly unique name, which is trivial for the
case of aircraft definitions (just use the aircraft name). This is
probably cleanest. But it does have the disadvantage that only
property files at the "root" of the property tree can define nasal
code. The "tree walker" mechanism above works anywhere.
Anyway, I thought I'd throw that out to the list before I start trying
to code something. There just doesn't seem to be an obvious Right
Thing for this problem. For the record, neither of the two latter
solutions will be hard to implement.
Andy
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
