On Tue, Apr 7, 2009 at 9:34 AM, Melchior FRANZ wrote:
> Well, so far the samples usually looked something like this:
> <ambient>0.2 0.4 0.1 0.5</ambient>. Doesn't look *that* bad, indeed.
> But in reality floats don't usually have just one digit after the
> comma. What about this?
>
> <foo>2345.1239878725027 235.237926028973 558.1283745628374
> 9.123242342346</foo>
>
> There goes the nicety.
Long ugly numbers or long ugly numbers. We can split them up and they are
slightly more readable, abut they are still long ugly numbers. We've made
things slightly longer, and slightly less ugly, but I don't know if we've
improved the overall score. It depends how we weight our priorities.
<foo>
<entry>2345.1239878725027</entry>
<entry>235.237926028973</entry>
<entry>558.1283745628374</entry>
<entry>9.123242342346M</entry>
</foo>
As long as this is only an XML markup
> question, the disadvantages are:
>
> - higher failure probability
Why is there a higher probability of failure? If I want to stretch to make
a point, I could suggest that forcing a developer to type in more xml tags
also increases the probability of making a typo. But I think this whole
point is very weak.
> - one has to know about the order and meaning of elements; they
> are not self-describing
You could call the property name something like "foo-rgba", then it is self
describing much like "altitude-meters" or "longitude-radians" is self
describing. And often order is implied and standard and the same all
through project. rgb or rgba for colors, xyz for 3d positions, etc. This
point is highly weak, and doesn't seem to help support your case.
Forcing programmers to keep track of the order of elements within the arrays
they define ... would that be an argument for eliminating arrays from all of
the computer world and replacing them with records of named fields instead?
I'm now starting to feel very sorry for all those programmers out there who
keep losing track of the order of their array elements ... getting their
colors and vectors and matrix elements all mixed up ... :-)
I know it sounds better to list 5 reasons rather than 1 or 2, but you need
to be careful if several of them are meaningless filler.
- it's a bastardized format: it's a custom format *within* XML
If I was scoring your argument here, this would be the first real point you
have to make.
- XML tools can only treat the entry as a whole, but not the elements.
> For example: a *.dtd file cannot validate the entries
> (http://en.wikipedia.org/wiki/Document_Type_Definition; not that
> I have any experience with that)
This is actually a continuation of the previous point ... although if
external tools just maintain the contents between tags verbatim when they
can't understand the structure any further, then this doesn't lead to
overall harm, just a situation where external tools can't deal with the
individual elements. Maybe bad? Maybe not bad? Can you cite an example
where this would be bad?
> - XML editors might not support such conglomerates (ok, weak argument
> ... who on earth uses an XML editor?! ;-)
Ok, so by my score, you have scored 1.5 out of 5 bullet points assuming we
score weak arguments as 0.5 and filler material as zero. Although mentally
I parsed your bullet points into an array so I might have got the order
confused and miscounted the score. :-)
> But that's all just XML representation. As soon as this thing ends up
> being stored in the property tree as new vec4, color etc. nodes, the fun
> is over:
>
> foo = '2345.1239878725027 235.237926028973 558.1283745628374
> 9.123242342346' (vec4)
> background = '0.12332975 0.123784967 0.28375891205 0.127456582302' (color)
>
> Should we make the property browser full-screen, so that one can still
> handle the entries? But that's only the response to your question:
I diverge from Tim in one sense that I don't support adding specific vec4 or
color aggregates to the property tree as atomic elements. I would much
rather support arbitrary length arrays of float or double or int (or even
boolean.)
However, I asked Tim about this and he said you reacted even more strongly
against arbitrary arrays then specific color3f, color4f, color3d, color4d,
vec3f, vec3d, vec4f, or vec4d types. Was this a clever move? Because it's
much easier to argue against a adding random and highjly specific aggregate
types versus generic arrays? If so, +1 for cleverness on your part. :-) So
by my understanding, you have steered Tim away from generic arrays into
specific aggregate types in earlier IRC/email discussion.
Let me ask a question to those that are concerned that the property browser
would be unable to handle the new types. Does this concern presuppose that
the property browser can currently be used to perform any and all desired
manipulations on the property tree as it exists now? Then I could
understand some concern if the new types would break that existing
"orthogonality". In that case, let me ask this: Is it possible to create a
new node in the property browser and give it a type? I tried just now and
couldn't discover the magic to do this. It doesn't seem possible.
Thus, I don't think the property browser currently offers complete,
orthogonal functionality to manipulate any aspect of the property tree.
Instead, it is primarily a "browser" of the existing tree with some
additional (but not complete) capabilities to manipulate the tree.
To say that adding array types to the property system breaks the property
browsers orthogonality might be a stretch if it is not orthogonal in the
first place?
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
