On Tue, 28 Nov 2023 23:34:30 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> Provide a public utility method for use by custom and core Nodes to simplify >> boilerplate around styleable properties as well as to save some memory. >> >> >> /** >> * Utility method which combines {@code CssMetaData} items in one >> immutable list. >> * <p> >> * The intended usage is to combine the parent and the child CSS meta >> data for >> * the purposes of {@code getClassCssMetaData()} method, see for example >> {@link Node#getClassCssMetaData()}. >> * <p> >> * Example: >> * <pre> >> * private static final List<CssMetaData<? extends Styleable, ?>> >> STYLEABLES = CssMetaData.combine( >> * <Parent>.getClassCssMetaData(), >> * STYLEABLE1, >> * STYLEABLE2 >> * ); >> * </pre> >> * This method returns an instance of {@link java.util.RandomAccess} >> interface. >> * >> * @param list the css metadata items, usually from the parent, must not >> be null >> * @param items the additional items >> * @return the immutable list containing all of the items >> * >> * @since 22 >> */ >> public static List<CssMetaData<? extends Styleable, ?>> combine( >> List<CssMetaData<? extends Styleable, ?>> list, >> CssMetaData<? extends Styleable, ?>... items) >> >> >> Problem(s): >> >> - the same less-than-optimal implementation is duplicated throughout the >> javafx code base which combines the parent and child styleable properties, >> using ArrayList wrapped in a Collections.unmodifiableList() >> - the capacity of underlying ArrayList might exceed the number of items, >> wasting memory >> - a potential exists for the custom component developer to inadvertently >> create a sub-standard implementation (i.e. return a List which does not >> implement RandomAccess interface), or forget to include parent's styleables. >> >> Non-Goals: >> >> - not redesigning the lazy initialization of STYLEABLES list >> - not changing the way styleables are enumerated in Nodes and Controls >> - not adding any new methods to JDK (collections) >> >> To Be Discussed: >> >> - it is not clear whether the order of styleables returned by <N extends >> Node>.getClassCssMetaData() is of any importance >> - the current spec for Node.getCssMetaData() specifies the return value as >> "The CssMetaData associated with this node, which may include the >> CssMetaData of its superclasses.", implying that it may or may not include. >> It is unclear whether it must include the parent's styleables (well, except >> the Node whose superclass is Obje... > > Andy Goryachev has updated the pull request incrementally with one additional > commit since the last revision: > > review comments I give up. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1296#issuecomment-1832755513