On 11 Oct 2010, at 10:52, Scott Hamilton wrote: > 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. James ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
