On Fri, Mar 20, 2009 at 10:22 AM, Stuart Buchanan wrote:
>
> Melchior FRANZ wrote:
>
> > This will probably become a flame-war, but I see no way to avoid
> > it.
>
I think you laid out your position in a very well thought out and fair
manner, backed up with many reasonable points and/or questions. If the
replies to this thread have a similar tone and include any thought and
insight, we shouldn't have a problem. :-) I can imagine an alternate
perspective so I'm looking forward to hearing that too.
> > Tim plans to extend the property system with compound data
> > types, such as VEC3, VEC4, or COLOR. We've discussed this three times
> > in IRC, and I've always pointed out why this is IMHO a *BAD* thing,
> > and why I strongly object. But now he has implemented it in his
> > source, and made that the base of further (desirable!) features.
> >
> > I don't want a flame war with Tim, but this needs to be decided
> > *now*. Otherwise we might end up having to decide whether we want
> > the (IMHO) "evil" property change *and* the nice features, or
> > neither. And that's not how a decision about one of our foundations
> > should be made!
> >
> > (To Tim's defense, he had planned to write an RFC to the devel list
> > about it, though he also intended to commit parts of the change before
> > that. And to my defense: I have told him that if he doesn't write the
> > RFC *soon*, then I will bring it up on the list!)
>
> I think it would be good for Tim to explain why more complex types are
> required, as I'm sure he will do shortly :)
Our current property system seems to match up well with C's view of data
types. As Melchior points out, we have always represented records/structs
as a subtree of properties hanging off a node. Arrays have been represented
using numbered nodes as in ... pos/vec[0], pos/vec[1], pos/vec[2] or
<pos>
<vec>1.1</vec>
<vec>0.5</vec>
<vec>-0.2</vec>
<pos>
or more verbosely:
<pos>
<vec n="0">1.1</vec>
<vec n="1">0.5</vec>
<vec n="2">-0.2</vec>
<pos>
The main argument I can anticipate for adhoc aggregate types would perhaps
be some sort of performance/space argument. If you want to store and
retrieve a boatload of vectors in the property system, having a child node
for each array element of each vector consumes extra space, and you burn
extra time accessing the individual elements. And an aggregate type could
be setup to have a better direct mapping to the required OSG/OpenGL form of
the data which would eliminate the need to convert the value each time it is
accessed.
But as Melchior points out, doing this sort of thing could open up a big can
of worms, and if space and access time is a key consideration, then is the
property system the best place for that sort of data?
If we start doing aggregate types, do we jump in with an adhoc approach and
create a few things here and a few things there as needed? This seems to me
to have the potential to explode in to a mess of accessor fuctions and
near-duplicate code that would be required for each new type or variant.
Perhaps *if* we want to extend the supported property types, we should think
*very* carefully about the overall design of the property system. Do we add
support for "arrays"? Could that be done in a reasonable manner, and could
that be leveraged for Tim's needs? Most of the key opengl data types are
things like float or int arrays.
My immediate thought is that one could write some fairly straightforward
> code to interpret a given property node with 3 child values as a Vec3.
> Could
> we subvert the property attributes to indicate that a given nodes contains
> a Vect3. That way internal code could interpret it as a Vec3, while
> external
> interfaces would be preserved.
I like this approach. We could easily write some helper functions that
would deal with aggregate types at a higher level. Internally, they are
still represented with the current property system, but a helper function
could collect all the children values of a node and present them as an array
of floats for instance. This would have a time/space overhead, but again,
if that's a problem, then that might be a sign that the property system
isn't the best place to store that data.
Like Erik, I'm very concerned about making the external interfaces more
> complex. One of the huge strengths of the property system at present is its
> simplicity, and I think that would be lost.
If we do move towards aggregate types, would we take a more "object
oriented" approach to data representation? It would be nice to have the
flexibility to then represent arbitrary collections of data like a C++
class. But if we do that, we really should support the concept of
inheritant, and what about attaching functionality/classes to the data.
But I'd still be interested in hearing Tim's perspective so I don't have to
guess at what that might be. :-)
Best regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
