Records: supertype?

[Kevin Bourrillion]

D'argh, sorry you sometimes have to remind me of basic things.

Well, that turns the thing upside down then. I'm not on Team Leave It Out,
then.

Naming... sure, something like 0.02% of all our classes/interfaces are
named exactly `Record`. That's higher than I'd have guessed. Clashing with
a java.lang name isn't a great thing; on the other hand we also have a
dozens of classes named exactly `String` and nothing ever really exploded
from it.

Of course, `AbstractRecord` is wide open. The main problem I see with that
name is that it will be weird if we end up allowing users to write their
own abstract records.  (It's *slightly* weird to have it named "*Record"
when it *is not a record* but it's already the case that Enum is not an
enum, so <meh>.)

I guess I would lean toward just using the straightforward name `Record`.


On Tue, Jun 11, 2019 at 2:05 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> We lose out on some future flexibility to add new methods, which might
>> amount to nothing, or might be a big deal.
>>
>
> Wouldn't we just introduce the type then once we needed it? It would be
> awkward, but would it be impossible or inadvisable?
>
>
> That would not be binary-compatible.
>
> Let's say we had
>
>     record Foo(int x) {}
>
> which was translated without a supertype.  Now we later try to add in the
> supertype, say with a `.toJson()` method, but don't recompile Foo.  Then:
>
>     Record r = (Record) aFoo;
>     String s = r.toJson();
>
> compiles, but throws some form of IncompatibleClassChangeError, since a
> Foo does not extend Record at runtime.
>
>
>

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190611/7d19998e/attachment.html>