On Wed, 21 Jan 2026 20:45:56 GMT, Michael Strauß <[email protected]> wrote:
>>> Attached properties are not exclusive to `Node`, we already have an >>> attached property for `Stage` in JFX 26 (`HeaderBar.prefButtonHeight`). >> >> you could also have `.of(Stage)`. >> >>> In any case, having something along the lines of >>> `AttachedProperty.from(node)` would entangle the implementation of `Node` >>> (and other classes) with `AttachedProperty`. >> >> How so? In fact, it completely separates the feature from whatever carrier >> is used. >> >> I really dislike this PR as it brings, in my opinion, unnecessary weight and >> code to the objects used everywhere for what seems to be a small side >> feature. I am ok with adding support to it, just not the way this PR does. >> >> I would say `AttachedProperty.of()` or something like that way is probably >> the least intrusive solution that I would support. > >> > Attached properties are not exclusive to `Node`, we already have an >> > attached property for `Stage` in JFX 26 (`HeaderBar.prefButtonHeight`). >> >> you could also have `.of(Stage)`. > > Yes, and that brings in `Stage` into the API of `AttachedProperty`, where it > doesn't belong. > > But I think I'm not even clear on what you are proposing here. This PR does > two things: > 1. It adds the `ReadOnlyProperty.getDeclaringClass()` method. > 2. It adds the `AttachedProperty` interface, which property classes can > implement. > > It seems like you don't object to the first addition, but only to the second > addition. But what exactly does your proposed code do, then: > > Set<AttachedProperty> props = AttachedProperty.from(node); > > > What are these `AttachedProperty` objects that I can get from a node? They > can't be the actual `Property` instances, as that's what you're objecting to. > What can I do with these objects? > @mstr2 : I don't understand the use case(s) then. > > @hjohn provided one: setting things like `-fx-hbox-hgrow` via CSS, so I > thought that's the kind of property one can stash in the Node.properties. > These properties might provide whatever extra information you want from the > attached properties, if I understand all this correctly. > > I do not understand why you need to add unrelated and unused fields and > methods to the regular property classes that neither need nor use it. Again, > if I understand it correctly. > > Does your JEP explain the problem in sufficient detail so even an old timer > like me who is perpetually stuck in Swing can understand? Some enhancements are motivated by missing features, some are motivated by rough edges in a taxonomy. Consider the recent addition of pattern matching for primitives in Java: that's not a feature people were missing sorely, it's just what you get when you smooth out the rough edges. This PR falls into the second category: it smooths out rough edges in the JavaFX property system. Properties carry metadata to tell you about themselves: their name and the object to which they belong. The declaring class is a missing piece of information (and it's _certainly_ not unrelated, as you say). Whatever criticism you have about why property metadata exists, your criticism should then also be levied against the existing "bean" and "name" metadata. The argument is the same. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3781219715
