From: Melchior F. <mf...@ao...> - 2009-04-07 13:50:25
|
* 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. |