[Flightgear-devel] Further properties heads-up - property objects.

2010-11-20 Thread James Turner
Moving us along the road to supporting better thread- and process- separation of the simulator elements, I've added a first attempt at at 'propertyObject'. This is a template wrapper for SGPropertyNode*, with conversion operators to/from the related primitive type. I.e:

Re: [Flightgear-devel] Further properties heads-up - property objects.

2010-11-20 Thread Jon S. Berndt
It has another interesting feature, suggested by ThorstenB - if you try to read an invalid path, it doesn't silently succeed - it throws an exception! This is to avoid lurking typos in property paths, which has been an issue. (I will be adding a 'weak' variant, that takes a default value, for

Re: [Flightgear-devel] Further properties heads-up - property objects.

2010-11-20 Thread James Turner
On 20 Nov 2010, at 14:53, Jon S. Berndt wrote: I'm wondering if the property code should just be left well enough alone... There's two answers to this: 1) it's not really tenable to have pieces of the API frozen in perpetuity - whether next year or in ten years, things evolve. [1] Either

Re: [Flightgear-devel] Further properties heads-up - property objects.

2010-11-20 Thread James Turner
On 20 Nov 2010, at 18:00, James Turner wrote: 2) I'm only proposing one non-backwards compatible change - the removal of tie/untie, and probably not in the next twelve months - certainly not the next six. I just checked and the JSBSim code makes extremely limited use of tie(), in a couple