matthew green <mrg@eterna.com.au> writes:
> how can you suggest restricting who can use what name?

Huh?

This seems obvious.  If you have a device has property 'foo' on it
that needs to be inherited by its child, and its parent also has
property 'foo' that needs to be inherited by its grandchild, you
cannot but lose.

You _need_ restrictions on who can use what names, i.e. a defined
protocol of property-passing, so that you know that you're using
properties in a way that can work.

Anything else will be ad hoc, and prone to failure as the system
involves.



> why should one
> particular bus/device/protocol get the glory of owning any particular
> name?  that doesn't extend.  (and i'm sure we don't want to introduce a
> real `namespace' attribute with it's own inheritants issues.  :-)

As long as you don't try to overlap two conflicting uses of a
particular name, you're fine in my book.

The point of defining each parent-child/global/etc.
property-passing/use protocol carefully is to avoid such conflicts.


Indeed, I think it generates a whole lot of work and doesn't scale
particularly well, and requires careful consideration when adding new
features.

But the alternative is no inheritance at all, except what's explicitly
done.  That would reduce properties to a symbolically-named version of
existing aux structures: with the ability to perhaps add new
properties in the config file in a better way than 'flags', and the
ability to query MD code for a device's property automatically.  I
think that has a bunch of serious drawbacks, most notably: incredible
space explosion to do anything useful, inability to set global
defaults, ... and i dunno what else.  8-)



chris