abstract datum ??

[Vicente Romero]

On 11/13/2017 05:17 PM, forax at univ-mlv.fr 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