David Megginson wrote:
>
> Julian Foad writes:
>
> > No - we have that in some places, but I was thinking recently that it's
> > not the right way to go. I think the only practical purpose is to
> > reduce clutter in the browser; but the property browser could and should
> > do this for us if we want it to.
>
> It also makes life easier for programmers, since we can pass around
> one node containing engine settings and nothing else.
Hmm ... I was about to agree with that ... but why is that useful? Think about how
you then use that node "controls/engines" that you are passing around: you assume that
it contains sub-nodes called "engine[n]", and you access them. If instead you pass
around the node "controls", the exact same functions can access the "engine[n]"
children in the same way. They won't be confused or hampered by the fact that that
node also has other sub-nodes that it isn't interested in ... will they? (OK, they
must access the children as 'children("engine")' rather than as 'children()'.)
Also, consider the generality of the way the property manager implicitly allows every
node to be indexed. This allows us to add each new feature in the singular:
/instruments/altimeter/{datum,serviceable,altitude-ft,...}
and then later to add more of them without changing the existing one:
/instruments/altimeter/{datum,serviceable,altitude-ft,...}
/instruments/altimeter[1]/{datum,serviceable,altitude-ft,...}
This is a really nice feature of the property manager. If there is a policy of
putting plural properties under a singular parent node, it doesn't accord with this
convenient practice. As you are considering moving the engine controls to a new place
in the tree anyway, you have the freedom to arrange them any way you like. That is,
it is not going to be backward-compatible anyway, and we already handle more than one
engine, so this particular case won't suffer additionally from a switch from singular
to plural. But consider that very many of the existing singular properties will
probably be pluralised at some time in the future.
I think I don't like mixing both ways. If we want each node to contain EITHER a list
of differently-name sub-nodes OR an indexed array (but not a mixture of both), then it
would make sense to make the property manager support this syntax directly - like
perhaps "engine/n" or "engine/[n]".
To me, in the existing property manager the notation "engine[n]" is the "correct
syntax" to describe the n'th engine and duplication of the name "engine" seems
logically wrong.
- Julian
