Where does this array come from ?

[Mateusz Romanowski]

Yes, but the record class author can still override Object methods, right?

If you have a lot record classes you might want to be allowed to centralize
some common behaviour for each subclass-record.


On Wednesday, April 8, 2020, Brian Goetz <brian.goetz at oracle.com> wrote:
> This strikes me as somewhat questionable.  Among other things, it is
unlikely that the implementations you would inherit from the abstract class
will meet the refined specification of those methods in jl.Record.
>
> On Apr 8, 2020, at 10:06 AM, Mateusz Romanowski <
romanowski.mateusz at gmail.com> wrote:
> Hi Brian,
> I was thinking of overriding toString() and other object methods using
this.getClass()' RecordComponents.
> Furthermore, the methods could be final or/and non-public.
>
> Mateusz
>
> On Wednesday, April 8, 2020, Brian Goetz <brian.goetz at oracle.com> wrote:
>> Turning this around, though: what’s the use case you have in mind where
interfaces aren’t good enough?  For _new_ code, you can always turn it into
an interface.  So I guess it would be for _exisitng_ abstract classes, like
Number?  Are there other examples you have in mind?
>>
>>> On Apr 7, 2020, at 2:33 PM, Mateusz Romanowski <
romanowski.mateusz at gmail.com> wrote:
>>>
>>> Hi,
>>> Could we allow record classes to extend abstract stateless classes
(same as
>>> in valhalla) that also extend java.lang.Record.
>>>
>>> I think that such functionality is needed (at least in JVM view) for
inline
>>> records.
>>>
>>> Should it also be made available to non-inline records?
>>>
>>> Thanks,
>>> Mateusz
>>>
>>>
>>>
>>> On Tuesday, April 7, 2020, Remi Forax <forax at univ-mlv.fr> wrote:
>>>> Create an an interface with a default method toJSON().
>>>>
>>>> interface DeriveJSON {
>>>>  public default String toJSON() {
>>>>    // use an object mapper or whatever you want here
>>>>  }
>>>> }
>>>>
>>>> so when you want a Point with a method toJSON(), you can write
>>>>  record Point(x, y) implements DeriveJSON { }
>>>>
>>>> With a little work, you can make toJSON to use a polymorphic inlining
>>> cache (good for benchmark) and with the upcoming hidden classes have a
>>> constant cost if it becomes megamorphic without generating bytecode.
>>>>
>>>> Rémi
>>>>
>>>> ----- Mail original -----
>>>>> De: "Stephen Colebourne" <scolebourne at joda.org>
>>>>> À: "amber-dev" <amber-dev at openjdk.java.net>
>>>>> Envoyé: Lundi 6 Avril 2020 15:45:48
>>>>> Objet: Re: Where does this array come from ?
>>>>
>>>>> FWIW, a colleague has previously argued that the toString of a bean
>>>>> should be JSON. At a company he worked at, all their beans were JSON
>>>>> and it apparently allowed them to build tooling on top of the
>>>>> toString. I'm not sure I'm convinced about JSON, but I do think a
>>>>> record is closer to a map than a list. And yes, Joda-Beans uses {} not
>>>>> [].
>>>>> Stephen
>>>>>
>>>>>
>>>>> On Mon, 6 Apr 2020 at 14:01, Brian Goetz <brian.goetz at oracle.com>
wrote:
>>>>>>
>>>>>> Perhaps we should rotate the punctuation every version just to
>>> discourage
>>>>>> parsing :)
>>>>>>
>>>>>>> On Apr 6, 2020, at 7:34 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>>>>>>
>>>>>>> I've was debugging a code yesterday that was printing
>>>>>>> Empty[]
>>>>>>>
>>>>>>> After some head scratching, trying to find an array of Empty, i
found
>>> that it
>>>>>>> was just an empty record
>>>>>>> record Empty() { }
>>>>>>>
>>>>>>> This is another clue that using square brackets for toString() is a
>>> bad idea !
>>>>>>>
>>>>>>> regards,
>>>>>>> Rémi
>>>>
>>
>>
>