Curtis Olson wrote: > 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. It's customary to wait for an RFC before arguing against it :)
> > Our current property system seems to match up well with C's view of data > types. Yes, but less well with a C++ world of more complex types. I know there's a tension when deciding what members of an aggregate to treat as naturally grouped and which to make accessible, but the current property system doesn't leave any choice. 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. > This is true, but I'm mostly concerned with surface syntax. > 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? > I don't see why not. The property system is a wonderful blackboard where all parts of fg communicate. I think we should be doing more to make it faster, multi-thread safe, reflect it across machines, etc. > 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. I'll do this if the RFC is shot down, but it doesn't solve the problem of ugly surface syntax. Also, I think the property system is a great place to dump 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. I haven't really thought about that yet. > > But I'd still be interested in hearing Tim's perspective so I don't have > to guess at what that might be. :-) Tim ------------------------------------------------------------------------------ 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
