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.
The idea of orthogonality is if you want to represent any point in 3d space,
you can do it by some combination of x, y, z components. The x, y, and z
axes are arranged orthogonal or at right angles to each other. Each axis is
completely independent from the other axes. You could imagine some other
space where the axis go in odd skewed directions that aren't at right angles
to each other, and you could still represent point locations, but the
numbers would be odd and hard to deal with, hard to add and subtract and
manipulate. So an orthogonal (at right angles, or said another way,
completely independent) components are an ideal way to represent a point in
3d space.
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.
Going back to the 3d point example. If we start adding components like a
curving axis in some random direction, or points that are only valid on the
2nd tuesday of every month, you wind up with a huge mess of special cases.
You lose the ability to perform simple functions (like + or -) on individual
components. Basic principles like 0 * x = 0 and 1 * x = x may no longer be
true. And if you have points that are only valid on the 2nd tuesday of
every month, it probably doesn't make sense to define a special data type
for that with mixed interdependent components, instead it makes sense to
think about what independent components we can use to build what we want.
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.)
Now, just to show you how fair I am, there is another side to this
discussion that is also just as important to consider.
Languages and API's often develop idioms and short cuts for things that are
heavily used. It makes life more complex in the sense that now you have to
learn the idioms that don't necessarily have any obvious literal meaning,
but once you learn the short cuts, you have a much more efficient way to do
something or express some particular idea. That can be very useful and very
practical for things you might do quite often.
So as I see it, the debate breaks down to practicality versus
orthogonality. Do we permit some idioms to develop for commonly used
operations or commonly used structures? That doesn't have to be a bad thing
in my view. But orthogonality is a really good thing, so we should strive
to maximize orthogonality and minimize idioms (to mix langauge and math
terminology in the same sentence.) We need to set a pretty high threshold
before allowing new idioms to be added, and especially when adding the first
idiom to a purely orthogonal system.
Speaking figuratively, what it looks like to me is that we will be adding
two more axes to our beloved X, Y, Z (figurative) system. The Tim1 axis and
the Tim2 axis ... both point directly to your two specific points in space.
That may be ok from a notational stand point, but I can understand the
resistance to poluting the well loved and well understood traditional X, Y,
Z space just because one person is solving a problem that involves a bunch
of points that line up on some other arbitrary axis.
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'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 want to support this. I want a nice, flexible, convenient system for
defining fancy graphical effects that leverage more and more of the
capabilities of modern graphics card for more and more realistic rendering.
But I really feel strongly about orthogonality of design and we would be
breaking that principle within our property system for the first time. I'm
very conflicted!
Curt.
On Fri, Jun 12, 2009 at 11:39 AM, Tim Moore <timo...@redhat.com> wrote:
> For various reasons I've let the discussion on my proposed property system
> extensions
> drop for a couple of months. You may recall that the proposal was to add
> two vector types,
> Vec3D and Vec4D, as primitive types in the property system. My rationale is
> that this
> improves readability of (the soon to appear) graphics effect files, which
> will use many
> 3 and 4-dimensional quantities, and solves a specific problem with updating
> values inside of
> OSG using property listeners. Some people are enthusiastic for this new
> functionality, one
> person is violently opposed, and there is much skepticism about why this
> might be necessary
> and if it is a good idea. Nevertheless, I think it's fair to say that the
> evolving consensus
> was that it would be OK to make this change as long as the new feature was
> not used in
> existing XML files and existing properties were not changed to use the new
> property types.
> I respect this desire for absolute compatibility, but my code at the time
> could not
> enforce this rule. Part of the delay of the last couple of months has been
> pondering whether
> I wanted to use the existing syntax and listener features and how to
> refactor SGPropertyNode
> to support a parallel property system.
>
> I've decided that graphics effects will use the extended properties. I
> simply don't want to
> write files that use the more verbose alternative, and I don't want to
> program around
> the update issues that are nicely solved by listeners. Furthermore,
> refactoring SGPropertyNode
> is turning out to be a big effort with very little real benefit.
>
> So, I propose to add an argument to readProperties that controls whether or
> not the new
> property types are recognized. By default they are not, so only code that
> explicitly calls
> for them will be able to use them.
>
> Comments?
> 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
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
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
