On 11/13/2017 05:17 PM, [email protected] wrote:
Hi Remi,
Hi Vicente,
[...]
But more fundamentally, given that we now have default methods and an easy way
to declare fields, i do not understand why the spec allow to declare abstract
datum.
By example,
interface Foo {
abstract int m();
}
abstract datum AbstractFoo(int x) implements Foo {
public int m() { return x * 2; }
}
datum Bar(int x, int y) extends AbstractFoo(x);
can always be simplified to:
interface Foo {
default int m() { return x() * 2; }
abstract int x();
}
datum Bar(int x, int y) implements Foo;
I think that what you are proposing is also a valid approach. I don't
think that the current one is written in stone so we have to evaluate
both. The benefit of abstract datum I would say is that you can abstract
not only behavior but data too in one place.
my example above also abstract over data.
Plus that you can create data classes only APIs.
yes, very true
Will this be enough support having abstract datum, well I guess that the uses
cases will benefit more one or the other.
Also having abstract datum give the users the benefit of using one approach or
the other which I think it's better than having only one option
having two ways of doing the same thing is usually not something you want apart
if there are clear cases where one approach is better than the other and
vice-versa.
Now, let see the arguments against using an abstract class:
- An abstract class contains implementation details. In theory, an abstract
class is independent that the subclasses but in reality, because an abstract
class shared part of the subclass implementations, an abstract class and its
subclasses are strongly coupled. To avoid that, abstract classes should be non
visible (like AbstractStringBuilder), given that a lot of people do not do that
means that using an abstract class is harder than one may think so not
introducing a way to specify an abstract data class is a win.
- generating codes inside an abstract class and the subclass and having
separate compilation that works is hard, by example, generating the generics
bridges in a hierarchy is hard.
As another example, the code below currently throws a VerifyError at runtime.
public class AbstractExample {
static abstract __datum A(int v) {
public final boolean equals(Object o) {
return o == this;
}
}
static __datum B(int v) extends A(v);
public static void main(String[] args) {
B b = new B(42);
}
}
so i think we should keep the design simple and avoid abstract data classes.
We should have an amber meeting soon and consider all the pros and cons
of each option.
Vicente
Rémi
Vicente
