> 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 

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 

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!
Flightgear-devel mailing list

Reply via email to