Feedback on Records in JavaFX

[Nir Lisker]

>
> I am interested to see more details on this.  If they have no fields, then
> could these have been turned into interfaces with default methods?


In the case of FontFaceImpl [1], it extends the following class:

/**
 * A FontFace is a @font-face definition from CSS file
 *
 * @since 9
 */
public abstract class FontFace {
    /**
     * Constructor for private implementation class only.
     */
    protected FontFace() {}
}

FontFaceImpl defines a public "canonical" constructor.

In the case of PseudoClassImpl [2], it extends the following class:

public abstract class PseudoClass {
    /**
     * There is only one PseudoClass instance for a given pseudoClass.
     * @param pseudoClass the pseudo-class
     * @return The PseudoClass for the given pseudoClass. Will not return
null.
     * @throws IllegalArgumentException if pseudoClass parameter is null or
an empty String
     */
    public static PseudoClass getPseudoClass(String pseudoClass) {
        return PseudoClassState.getPseudoClass(pseudoClass);
    }

    /** @return the pseudo-class state */
    abstract public String getPseudoClassName();
}

In both cases, the implementing classes are the only subclasses of the
abstract class provided by the library.

[1]
https://github.com/nlisker/jfx/blob/Records/modules/javafx.graphics/src/main/java/com/sun/javafx/css/FontFaceImpl.java
[2]
https://github.com/nlisker/jfx/blob/Records/modules/javafx.graphics/src/main/java/com/sun/javafx/css/PseudoClassImpl.java

On Sun, May 10, 2020 at 6:05 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> In the examples you had with abstract classes, did they mostly have
>> fields, or no?
>
>
> No, point 3 is specifically "classes that behave like records, but
> they extend an abstract class that does not have any fields”.
>
>
> I am interested to see more details on this.  If they have no fields, then
> could these have been turned into interfaces with default methods?
>
> Also, did you consider the point I made about accessor names of boolean
> fields?
>
>
> This is a special case of the more general “why didn’t you just adopt the
> getX() naming convention.”
>
> The naming convention was one of the most controversial aspects of this
> project.  To many, it was “just obvious” that we should have adopted the
> JavaBean naming convention, because so much code out there uses it.
>
> This is one of those areas where the perspective of a language design, or
> of platform steward, may differ significantly from that of the
> programmer-on-the-street.  To a programmer, it’s all “just Java” — the
> language, the core libraries, the JVM, and even frameworks like Spring.
> But a language has different constraints, and therefore may equilibrate to
> different conventions, than a library or even an entire ecosystem of
> libraries.
>
> The JavaBean naming conventions are _just one possible convention_.  This
> is the advantage libraries have over languages — that different libraries
> can pick different naming conventions, as the domain demands — libraries
> have the option to “have it both ways” in ways languages do not.  To the
> extent that the language gets into mandated-member-generation at all, on
> the other hand, it only gets to pick one naming convention for all
> programs, for all times.  And while I understand why so many Java
> developers would naturally assume that we’d pick the JavaBean conventions,
> burning that convention into the language would have been a mistake.  The
> _only_ convention we could justify from a language perspective is to name
> the accessors the way we did (and then, only because Java made the choice,
> for better or worse, to have separate namespaces for fields and methods.)
>
> (Those that think that getX() is a “standard” in the community have
> probably not noticed that new APIs added to the platform over the past 5 or
> so years have tended to drift towards the x() accessor convention rather
> than the getX() convention.)
>
> So if we couldn’t bend for getX(), we certainly couldn’t bend for the
> exception to getX() — isX().
>
>
>