Melchior FRANZ wrote:
> * 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?
>
No. Material animations will set the effects properties.
> 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.
You've used the "GUI slider on red" example before as a case that would
be inconvenient with colors stored as vector properties. So what would you
do to signal the update?
>
> 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.
How / where do you document that a parent node requires this explicit
listener activation?
>
> 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.
Some people want general arrays a property values :)
Tim
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
