No, I’m talking more broadly.
abstract class A implements PureObject {
int a;
}
abstract class B extends A {
int b;
}
pure class C extends B {
int c;
}
Now C is a final, pure class with fields a, b, and c. A and B are abstract
superclasses of C.
There’d be details to work out, but this is not an impossible lift. The
question is whether the return on complexity is there or not.
On Nov 18, 2021, at 5:58 PM, Remi Forax
<[email protected]<mailto:[email protected]>> wrote:
________________________________
From: "Brian Goetz" <[email protected]<mailto:[email protected]>>
To: "Kevin Bourrillion" <[email protected]<mailto:[email protected]>>
Cc: "Dan Heidinga" <[email protected]<mailto:[email protected]>>, "daniel
smith" <[email protected]<mailto:[email protected]>>,
"valhalla-spec-experts"
<[email protected]<mailto:[email protected]>>
Sent: Jeudi 18 Novembre 2021 23:34:51
Subject: Re: EG meeting, 2021-11-17
I think it is reasonable to consider allowing bucket two classes to be
abstract. They could be extended by other classes which would either be
abstract or final. The intermediate types are polymorphic but the terminal type
is monomorphic.
A similar argument works for records.
I suppose you are talking about empty (no field) abstract classes.
We need that for j.l.Object, j.l.Number or j.l.Record.
From a user POV, it's not very different from an interface with default methods.
Rémi
Sent from my iPad
On Nov 18, 2021, at 5:27 PM, Kevin Bourrillion
<[email protected]<mailto:[email protected]>> wrote:
On Wed, Nov 17, 2021 at 7:05 PM Dan Heidinga
<[email protected]<mailto:[email protected]>> wrote:
Let me turn the question around: What do we gain by allowing
subclassing of B2 classes?
I'm not claiming it's much. I'm just coming into this from a different
direction.
In my experience most immutable (or stateless) classes have no real interest in
exposing identity, but just get defaulted into it. Any dependency on the
distinction between one instance and another that equals() it would be a
probable bug.
When B2 exists I see myself advocating that a developer's first instinct should
be to make new classes in B2 except when they need something from B1 like
mutability (and perhaps subclassability belongs in this list too!). As far as I
can tell, this makes sense whether there are even any performance benefits at
all, and the performance benefits just make it a lot more motivating to do what
is already probably technically best anyway.
Now, if subclassability legitimately belongs in that list of
B1-forcing-factors, that'll be fine, I just hadn't fully thought it through and
was implicitly treating it like an open question, which probably made my
initial question in this subthread confusing.
--
Kevin Bourrillion | Java Librarian | Google, Inc.
|[email protected]<mailto:[email protected]>
