[Flightgear-devel] Further properties heads-up - property objects.
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:
simgear::PropertyObjectint frameRate(/sim/rendering/fps);
int theFrameRate = frameRate; // maps to getIntValue
frameRate = 1234; // maps to setIntValue
if (frameRate == 789) {
...
}
and so on. (The std::string variant tries to convert nicely to char*
too, where possible)
To the extent possible by C++, once you've declared a property object, you
should be able to treat it exactly like a plain int/double/bool/string, but of
course the actual storage is the property. (if you find areas where this falls
down, of course let me know, or fix them)
The goal of the PropertyObject is that it's hard to use inefficiently - it
lazily does the the property lookup, but caches the result.
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 the cases where people
want to read a property that might not exist)
Suggestions are most welcome - for example there's no read-only version at the
moment, but there could be.
Apart from being a nicely short syntax, there is another goal - tied properties
are a menace, for thread-safety, for un-tie-ing cleanly on subsystem shutdown,
and for not firing change listeners. My hope here is to create something that
has semantics that work in a multi-threaed or multi-process world - but which
is as painless to use in code as a tied value. I think I've succeeded, but time
will tell.
(One other thing I will be adding, probably to SGPropertyNode itself, is a
nicer listener syntax, since I'm aware of various pieces of code that use tied
setters as a value-changed notification - SGPropertyChangeListener is a rather
cumbersome solution for this)
I'm not going to start converting tied properties to use propertyObjects next
week, or next month, but certainly next year. The hope is that by that time,
this code is mature, efficient and so on - so please try it, use it and fix it!
Regards,
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/msIE9-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further properties heads-up - property objects.
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 the cases where people want to read a property that might not exist) ... I'm not going to start converting tied properties to use propertyObjects next week, or next month, but certainly next year. The hope is that by that time, this code is mature, efficient and so on - so please try it, use it and fix it! Regards, James This concerns me a bit. JSBSim grabs a copy of the relevant simgear code to support properties once every couple of years. When JSBSim is built within FlightGear, we of course just use what's there in the FlightGear tree. But, when JSBSim is incorporated into other products, they use what we have in our codebase. I'm concerned that at some point the property system will evolve to the point where serious conflicts arise, and backwards compatibility is broken. We (JSBSim) depend on the property system. I'm wondering if the property code should just be left well enough alone... Jon -- 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/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further properties heads-up - property objects.
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 JSBSim needs to be prepared to stay in sync (eg, update from the Simgear code monthly or quarterly), or you need to decide that you want your own code, and fork it 'properly' - at which point we'd make a bridge in the FG side between JSBSim properties and SimGear ones - which is fine. My guess is the latter is going to work better for you, though it's more effort upfront. However, all that being said: 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 of source tiles total. If you'd rather not use the new property features, that's fine - it'll just mean more boilerplate code to use the existing APIs when tie() does finally cease to exist. (And you can carry on shipping a version of props.hxx/.cxx with JSBSim-standalone, that *does* include tie(), to avoid breaking existing users who might have tie in their code) As far as I'm concerned, all of 2) is my problem - if I remove tie(), then I have to fix all the previous users, including JSBSim. You don't need to do anything, and I don't expect any JSBSim breakage. I think you *ought* to do something about 1), since you're following a pattern that is going to cause pain for someone, sooner or later, but that's just my opinion - it's your code! Regards, James [1] - especially, since the property code was designed, multi-core machines have become rather common! -- 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/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further properties heads-up - property objects.
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 of source tiles total. If you'd rather not use the new property features, that's fine - it'll just mean more boilerplate code to use the existing APIs when tie() does finally cease to exist. (And you can carry on shipping a version of props.hxx/.cxx with JSBSim-standalone, that *does* include tie(), to avoid breaking existing users who might have tie in their code) Anders point out my checking was flawed - since tie() gets renamed to Tie() - doh. Since I assume changing every JSBSIm use of Tie() is a non-starter, we'll have to devise something special on the FG side, to keep tie() 'apparently' working for JSBSim - not ideal, but probably doable. Anyway, something for the future! Regards, 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/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
