On Mon, 1 Jun 2026 23:51:52 GMT, Martin Fox <[email protected]> wrote:
> > Maybe you moved backdrop options to `Stage` because that allows > > `StageBackdrop` to essentially be an immutable key that identifies a > > backdrop. > > No, it's because the same `StageBackdrop` can be installed on multiple stages. > > The problem is partly one of naming. A StageBackdrop object doesn't represent > a backdrop, it encapsulates the information needed for a stage to build a > backdrop. Leaving naming discussions aside, I'm questioning the semantics here. I don't really understand what you mean with this sentence. What information is encapsuled by a `StageBackdrop`? As currently proposed, it has no configurable payload and it is used like an immutable identifier; aside from its name, there doesn't seem to be any information. Your implementation confirms this interpretation, as you're just deriving an int-based ID from the backdrop name, which is just another form of the name itself. > That creation info is sharable across stages but each actual backdrop is > bound to a specific stage. Once a stage's backdrop is built there needs to be > a separate API for accessing it and changing its dynamic options. I don't > think it's a good idea to try to make one object serve both purposes. In the class metaphor of OOP, the class is the blueprint of a thing, and the instance is the thing itself with concrete values. The methods for accessing the values are purposefully colocated with the class that defines their meaning. You're proposing to have the configuration API be located on a different class, which is very unusual. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-4597699973
