20,741
edits
Howto:Extend Nasal: Difference between revisions
Jump to navigation
Jump to search
m
→Wrapping Classes as Nasal Objects (ghosts)
| Line 284: | Line 284: | ||
= Wrapping Classes as Nasal Objects (ghosts) = | = Wrapping Classes as Nasal Objects (ghosts) = | ||
To be written by Hooray & Zakalawe | '''To be written by Hooray & Zakalawe''' | ||
There's a plan to eventually unify all those helpers and provide them as part of the FGNasalSys class, so that they automatically become available to all users of the Nasal subsystem. | Quoting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29032.html | ||
<pre> | |||
One problem is that functions like airportinfo() already do *way* too much, and making it do more will not | |||
help. We need to stop exposing *functions* to Nasal, and start exposing *objects*, with properties. | |||
Notably, amongst the airportinfo() structure is a runways hash, which contains data that depends on the Airport Scenery data - this means it can trigger the | |||
lazy loading of that data, and hence require a disk access. I've noticed the same problem with the map dialog. Most people accessing airportinfo() only want | |||
one or two pieces of info, but we compute the whole lot each time. I realise that making proper Nasal ghosts for FGPositioned, FGNavRecord, | |||
FGRunway, FGAirport is more work, but it would be the right path to putting the Nasal API on parity with the C++ one, and would enable a huge amount of | |||
FMS/digital charting/ATC functions to be built in Nasal. | |||
If that sounds impossible, then I'd strongly advocate creating separate special purpose-functions in the short term, that do *one* thing, and be more easily | |||
subsumed if/when we properly expose the C++ types to Nasal. | |||
Yes I'd like to second the idea of returning objects (with attributes | |||
and methods for doing interesting things), I'm guessing we don't need to | |||
abstract it too far from what is provided underneath. | |||
However I really like the idea of getting back an array of airports | |||
within some radius of a centre lat/lon pair, and/or within a bounding | |||
box (2 or 4 lat/lon pairs), and if the same could be done with other | |||
navigation elements in nav.dat it would be most excellent! | |||
Well, this is exactly what all the query methods on FGPositioned do - the | |||
problem is, they return FGPositioned subclasses, which aren't much use to Nasal | |||
right now! Exposing the FGPositioned query interfaces (and the related, | |||
specialised versions on FGAirport, FGNavRecord, etc) would be quite quick, but | |||
it's pointless until the results are useful / interesting to Nasal.. | |||
One interim step - it would be possible to wrap the query methods, but write | |||
code (exactly as airportinfo() is currently implemented!) to map the | |||
FGPositioned subclasses to a 'static' naHash. That's easier than creating | |||
proper naGhosts, and could have a forwards-compatible APi when the ghosts are | |||
written. | |||
</pre> | |||
For the time being, it's a good idea to take a look at the FGPositioned wrappers for the navdb to see how this is done in Nasal, see [https://gitorious.org/fg/flightgear/blobs/next/src/Scripting/NasalPositioned.cxx $FG_SRC/Scripting/NasalPositioned.cxx]. | |||
There's a plan to eventually unify all those helpers and provide them as part of the FGNasalSys class, so that they automatically become available to all users of the Nasal subsystem. | |||
= Passing Pointers to Nasal scripts = | = Passing Pointers to Nasal scripts = | ||