Where does this array come from ?

[Brian Goetz]

No, what I meant was: if you want a different implementation of these 
methods (which should be rare), you write them the normal way.

On 4/8/2020 11:58 AM, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "Brian Goetz" <brian.goetz at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "Mateusz Romanowski" <romanowski.mateusz at gmail.com>, "amber-dev" <amber-dev at openjdk.java.net>
>> Envoyé: Mercredi 8 Avril 2020 16:47:41
>> Objet: Re: Where does this array come from ?
>> At one point we considered having a way to invoke the default implementation
>> (e.g., default.toString()), but after more consideration, felt this didn’t
>> carry its weight.
>>
>> The obvious answer is: write it!
> There is still a code i have submitted to improve the meta-factory used by the record implementation which is in limbo.
>
> Also, i think the way to do it properly is to patch the compiler to see the method of java.lang.Record as non abstract (the symbols in the scope), so a call like super.equals() will compile and then let the compiler to replace that call with an indy, is it what you have in mind ?
>
> Rémi
>
>>> On Apr 8, 2020, at 10:45 AM, forax at univ-mlv.fr wrote:
>>>
>>> This remember me something,
>>> let suppose I have this record,
>>>   record Point(int x, int y) { }
>>>
>>> and I want toString() to return the same string as usual but with a bang " !" at
>>> the end,
>>> how am i suppose to do that ? (obviously the code has to work even if i add new
>>> record components).
>>>
>>> Rémi
>>>
>>> ----- Mail original -----
>>>> De: "Brian Goetz" <brian.goetz at oracle.com>
>>>> À: "Mateusz Romanowski" <romanowski.mateusz at gmail.com>
>>>> Cc: "Remi Forax" <forax at univ-mlv.fr>, "amber-dev" <amber-dev at openjdk.java.net>
>>>> Envoyé: Mercredi 8 Avril 2020 16:34:37
>>>> Objet: Re: Where does this array come from ?
>>>>> Yes, but the record class author can still override Object methods, right?
>>>> Sort of!  jl.Record, the implicit super type, overrides equals, hashCode, and
>>>> toString with refined (strengthened) semantics.  So you can’t override
>>>> Object::equals, but you can override Record::equals (which of course has to
>>>> conform to the semantics of Object::equals, but also does more.)