Component deprecation

[Brian Goetz]

Note that to emulate the old protocol you would have to explicitly 
declare a 3-arg ctor _and deconstructor_. But there's no problem with 
that (once we have the brutal syntax discussion about deconstructor 
declaration (not now, Remi.))

I mostly agree that deprecation here is kind of silly, but since 
@Deprecated is "just" an annotation, I don't object to it being allowed.

Serialization should be fine, as we go through a similar process for 
encoding/decoding fields as default serialization, so the extra field 
will be ignored.

On 1/9/2020 10:17 PM, Tagir Valeev wrote:
> I can imagine that the record component loses its meaning and now
> should be ignored.
>
> E.g. record Point(int x, int y, @Deprecated int z) {} // the budget
> was cut, so we are building 2D game now instead of 3D.
>
> In this case, to make it convenient for new call sites while keeping
> the old call sites compilable, it would be good to introduce
> non-canonical constructor:
>
> record Point(int x, int y, @Deprecated int z) {
>    public Point(int x, int y) { this(x, y, 0); }
> }
>
> Probably we can mark a canonical constructor as deprecated if at least
> one record component is deprecated because using the canonical
> constructor you're essentially using the deprecated component.
>
> However, to me it looks much better to remove component at all in this
> case, and emulate it for old call sites:
>
> record Point(int x, int y) {
>    @Deprecated public Point(int x, int y, int z) { this(x, y); }
>    @Deprecated public int z() { return 0; } // or even throw
> }
>
> This should be source and binary compatible change. The only problem
> is the deserialization of old streams (provided the record is
> serializable).
>
> With best regards,
> Tagir Valeev.
>
> On Fri, Jan 10, 2020 at 6:42 AM Dan Smith <daniel.smith at oracle.com> wrote:
>>> On Jan 9, 2020, at 10:51 AM, forax at univ-mlv.fr wrote:
>>>
>>> Currently you can not deprecate a record component unlike in Scala or in Kotlin.
>>> We can either allow @Deprecated or pretend that people will never make mistake, change their mind, specification will never change, etc
>> Setting aside implementation details, and whether there's any change to be made here: I'm curious about what you intend a deprecated record component to *mean*. How do you deprecate a single parameter of a constructor? A concrete example could be useful—I can believe there might be something there, but I'm struggling to see it.
>>
>> A related StackOverflow discussion about deprecated parameters/locals:
>> https://stackoverflow.com/questions/14627313/what-does-deprecated-mean-on-method-parameters-and-local-variables
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200109/b3b1b6ee/attachment.htm>