john.r.rose at oracle.com
Sun Feb 9 21:08:58 UTC 2020
Good point. For our purposes the abstract ctor must always resolve to Object. And it must have the empty signature right?
A small remaining point: There might be other use cases in the future for other configurations which make logical sense in the same way. If so we can expand the permissions to other constructors besides Object::<init>()V. For now that’s the only one we care about delegating you.
Have I got it now?
On Feb 9, 2020, at 7:26 AM, Brian Goetz <Brian.Goetz at oracle.com> wrote:
> I think what dan is saying is that you are positing a degree of freedoms that is unnecessary. We want to have abs classes that can be a base for both inline and idents. An abstract ctor can be the indicator of this. But, why bother with allowing such a class to extend one that doesn’t meet the same requirements? They will be useless for in lines anyway. Require that the ctors be “abstract all the way up.”
> Sent from my iPad
>> On Feb 9, 2020, at 1:08 AM, John Rose <john.r.rose at oracle.com> wrote:
>>> On Feb 8, 2020, at 9:08 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>>> Oh, yeah, if we need to make sure that code gets executed (for identity classes), that will affect the design.
>> That’s the root of the stuff you found perhaps unnecessary.
>> It could be done the way you propose also, but adding the
>> ability of the invokespecial to turn into a “pop”, and dealing
>> with the loss of Object::<init> as a handy point of reference,
>> makes for a different, less regular set of JVM changes.
>> I could go either way on having Object::<init> changed to
>> be abstract, but I think it’s safer to leave it exactly as is,
>> and then just say “inlines never get there”.
>> — John
More information about the valhalla-spec-observers