> Extend Nasal property methods to support relative paths. > > All methods exposed to the Nasal props module now accept an > optional first parameter refering to another node by a relative > path.
I'm a bit torn on this change; making APIs more flexible is usually a good thing. However, the cost of property path parsing has previously shown up in profilers as a source of dynamic allocations and overhead. Historically, on the C++ side; I can believe that in Nasal the extra parsing overhead is lost in general Nasal overhead, but still, the idea of the existing API was to force you to design & work 'the right way', i.e cache leaf leaf nodes as objects, instead of repeated referring to leaves by a relative path. If you just want a quick and dirty way to read one property, we have getprop / setprop - for any other use, you should be doing what the API already supported; getting a props.Node object for the leaf, and then manipulating it with no further string/path handling. At least, I would prefer that getValue and setValue did not support this, since it will surely encourage convenient-but-inefficient styles of use. (I would also be happy to extend props.nas with helpers to make the above syntactically more compact, but I think such sugar can all be done on the Nasal side) Regards, James ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
