Curtis Olson wrote: > Hi Tim, > > I have one concern that I may not have voiced clearly before. > > I tend to think about these design choices in terms of what is often > called "orthogonality". The idea stems from the world of vectors. > ... > > So if you translate that concept over to computer languages, or computer > API's, I believe strongly that these things also work best when they are > "orthogonal". In other words, we want a minimal set of independent > components we can use to specify or accomplish what we want. This makes > for clear and understandable and maintainable code. ... > > So as you speak of adding Vec3 and Vec4 types to the property system, I > immediately have orthogonality concerns. We seems to be adding a > specialized core type that is only good for one purpose along with the > specialize code to handle just that particular type, and we are moving > against the concept of orthogonality (which I feel is highly important > when designing api's, computer languages, vector spaces, etc.) > You've talked before about wanting to support general array data in properties; that is not a big step from what I've done with Vec3D and Vec4D. If I support that and don't have Vec3D and Vec4D I would need to do some extra work to hook those values up to their OSG counterparts, but nothing major. However, this is admittedly a distraction from getting effects and shadows working, and I would rather start with the vector types and arrays later. Some will suggest that all this surgery on the property system is the distraction, and the point is well taken.
> This might come as a very late suggestion, but would it be able to > derive a new class using SGPropertyNode as the base (maybe call it > SGPropertyNodeExt) and then add your new types to the derived class? I > supose then you wouldn't be able to use the same xml reader/writer code. I've noodled around with this a couple of months. The xml I/O is a major block, but the more general refactoring job seems like a huge waste of time if the option of restricting the use of extended features via the reader is acceptable. > > I'm very conflicted on this one. It is messy. So far I haven't seen a > slam dunk argument either way. We are trying to balance convenience and > ease of use against well conceived design. Typically we try to build > more complex structures out of simpler base structures. But this is a > case where the interdependencies of our property system, xml > reader/writer code, and opengl/osg seem to force a cascading sequence > where one change implies another which implies another and we are right > back to specific vec3 and vec4 types and it's really hard to create an > optimized and convenient system that is more generalized and maintains > pure principles of orthogonality. I mostly agree with this, though I continue to maintain that the new types are fully in the spirit of the property system, moreso than array types would be. I'd also suggest that no one here knows the right answer to this question, making the option of playing with the new features in a "playground off to the side" attractive. Tim ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
