abstract datum ??

[Vicente Romero]

Hi Remi,

On 11/10/2017 09:15 AM, Remi Forax wrote:
> ----- Mail original -----
>> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>> À: "Robert Gibson" <robbie_usenet at yahoo.co.uk>, "Vicente Romero" <vicente.romero at oracle.com>
>> Cc: "amber-dev" <amber-dev at openjdk.java.net>
>> Envoyé: Jeudi 9 Novembre 2017 19:22:35
>> Objet: Re: [datum] initial public push (IPP)
> [...]
>
>>> And there are more pitfalls of course around inheritance, although the rule of
>>> “only one concrete class in a hierarchy” eases the pain a little.
>> Not sure about this. On the one hand, under the current proposal, only
>> concrete datum (leaves in the hierarchy) get an equals method. So you
>> could just say that the stricter equals and the associated bridge is
>> only generated on such leaves. But that leaves out cases like these:
>>
>> abstract datum AbstractPoint(int x, int y);
> it works using generics with a recursive bound that describe itself
>
> abstract datum AbstractPoint<P extends AbstractPoint<P>>(int x, int y) {
>    **synthetic** boolean equals(Object o) {
>      if (o instanceof AbstractPoint) {
>        return equals((AbstractPoint<?>)o);
>      } else {
>        return false;
>      }
>    }
> }
>
>> datum Point(int x, int y) extends AbstractPoint(x, y);
> datum Point(int x, int y) extends AbstractPoint<Point>(x, y);
>
>> Point p = ...
>> p.equals(""); //error
>> ((AbstractPoint)p).equals(""); // ok?
>>
>> And if we want the last statement above to be an error, does it mean we
>> have to generate an equals(AbstractDatum) on the intermediate leave?
>> Maybe. But then:
>>
>> AbstractPoint ap = ...
>> Point p = ...
>> p.equals(ap); //error
>> ((AbstractPoint)p).equals(ap); // ok?
>>
>>
>> Seems can-of-wormey...
>>
>> Maurizio
> 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. Plus that you can create 
data classes only APIs. 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

>
> regards,
> Rémi
Vicente