* Anders Gidenstam -- Tuesday 07 April 2009:
> Some additional thoughts on atomicity: we have several levels of "setting
> a bunch of values in one go" in FlightGear:
The whole discussion is still much too detached from any actual use case.
What aggregate data block would we repeatedly set/read under circumstances
where speed actually matters? The XML shader files are read just once
when the model is loaded, no?
What other cases are there where reading three individual properties
is a problem, but reading one vector property isn't? And you can
easily write a small helper function that does the reading, so it's
in no way more annoying.
Atomicity is almost never an issue. Data set in the tree doesn't magically
affect c/c++ code, anyway. This has to be coded, in one of three ways:
tying, polling, listening. (Neither of them is thread-safe, no matter
if vector types exist or not. So this is IMHO not a criterion for the
decision.)
But apart from that you can have atomicity already now, as I've said
earlier. What's more natural than a color node where you can access all
components individually (e.g. attach a GUI slider to the <red> element):
<color>
<red>0.1234</red>
<green>0.431</green>
<blue>0.2341</blue>
<alpha>1</alpha>
</color>
... and when you are finished with manipulating the color, you
validate the color change by "updating" the <color> node. After
all the <color> node stands for color branch with its elements.
A listener on the <color> node copies the *atomar* color to the
GUI/material, etc. This only looks tedious if you ignore that it
can all be hidden in a few simple helper functions, like fgSetColor().
It's not like vector data types wouldn't also require lots of new
functions to work.
This approach is logical, generic, and doesn't break anything. You
can use the same technique on a font/{name,size,slant} aggregate,
or even a nested one: font/{name,size,slant,color/{red,green,blue}}
You don't have to change a core library for applying the same
principle to other aggregate types. You can implement it in Nasal only,
or C++ only, or mixed.
Implementing a "color" or "vec3" property is only picking out very
special cases and pretending they are in some way generic, while
ignoring all the other possible aggregate types. This is needlessly
extending a very functional, generic system instead of just *using*
it.
m.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
