[records] translation strategy (factory methods)
john.r.rose at oracle.com
Fri Jan 10 19:12:34 UTC 2020
On Jan 10, 2020, at 8:22 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> So my vote is #0. But, if we have a story for moving _all_ classes towards factory construction, then we should make sure records play well. I don't think we have to do anything now for which we'd regret inaction, because whatever problem we have with legacy records, we'll already have with every class ever written.
That’s fair. And good observations about the siren song.
The main downside is that records will be hard to convert to
inlines without client recompilation, unless we create some
as yet unknown tech. for morphing the new/dup/invoke<init>
dance into a factory call. (The problem is doing something
with the result of the “new” instruction so it ends up being
an immutable inline reference at the end of the dance, but
during the dance it must somehow absorb side effects from
the invoke<init>. And the dance is not always a simple and
local bytecode pattern; stuff like `new X(new Y(z))` is not
local in shape.)
But I agree that this is a larger problem than just records;
many non-record classes are potentially migratable to inlines.
So there’s limited value, and real irregularity, for special
pleading on records.
(OK, we’ve got that on record.)
More information about the amber-spec-experts