CssMetaData.combine()

[Andy Goryachev]

Dear colleagues:

there were a couple of comments after I withdrew https://github.com/openjdk/jfx/pull/1296for reasons of frustration, so I wanted to respond to those in the openjfx list.

> I pondered that back when I was working on replacing these static initializers with the .of collection variants. It doesn't work here for problem stated above - we need to modify an unmodifiable list, which is why I didn't touch them in that pass. While the proposed method is useful for eliminating some ugly syntax, cementing a questionable API with more a public API doesn't seem to me like the right direction. If the method is made internal only, then that's fine. Alternatively, if the method is made useful outside of this specific context, then even if it won't be used here, it could be used in other places, and that's also fine.

Even though the syntax is ugly, the current implementation of the static getClassCssMetaData() is nearly perfect, considering the lack of some kind of a 'lazy' keyword in java.

What the current code does is two things - a lazy initialization, meaning the code will get executed only when needed, and it has zero per-instance overhead.  I don't think anyone can suggest a better way of doing it.

I don't buy Nir's argument about "questionable API".  The API is codified by Node.getCssMetaData() and the current implementation will be perfect with the proposed utility method (and maybe we can address some other comments from https://git.openjdk.org/jfx/pull/1293#discussion_r1411406802 ).

I do like what Michael suggested - is to provide a (better) explanation for CssMetaData.combine(), including the requirements on the user code that wants to provide CSS styling for the custom controls.

I still think this PR has merit, the custom component devs will certainly benefit from it, a few bytes and cpu cycles would get saved.  I don't mind reopening the PR, may be extending its scope to use the new utility in all the core controls and skins.

And I would be very much interested to hear from Nir his idea of an API that is not questionable.  I think we'll all benefit from learning how to make javafx better.

-andy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20231201/5b790beb/attachment-0001.htm>