> I took a bit of a closer look. Although I think I can provide real > properties, there will likely be quite a lot of edge cases with > properties created on demand, and which only should exist while a Node > lives under a certain Parent.
I think this is the wrong framing of what these properties actually are. Attached properties should be like regular properties, except that their API is declared in another class. Everything else should be the same; most crucially, they should have the same lifetime as the object to which they are attached. I would be astonished to learn that a property that I've set on a node suddently disappears just because I've moved the node around. In addition to that, attached properties should not be limited to container configuration; they are also suitable for rarely-used or special-purpose API. While it is true that attaching a HBox.margin property to a node is only relevant when the node is placed into a HBox, this doesn't mean that the node and its parent container are now eternally entangled. Doing that creates lots of problems for basically no benefit at all. Attaching HBox.margin to a node should be interpreted as: "if this node is placed in a HBox, then the following margin should apply". Attached properties should also not be implemented such that they hold a reference to their parent container, they should only add state to the object to which they are attached. With this in mind, I think the edge cases you're hinting at disappear. > That said, transitions will probably work now, however, looking at the > type of properties, none of these seem suitable candidates for any > reasonable form of transition (most are booleans or enums, a few > margins, and a few integers for row/column indices/spans). I don't think that it matters much if the transitions are reasonable, what matters is that they are consistent with normal properties.
