[
https://issues.apache.org/jira/browse/THRIFT-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786076#action_12786076
]
Jonathan Ellis commented on THRIFT-529:
---------------------------------------
> Your reference to Deprecation doesn't solve anything
the problem it solves is breaking existing code, not the "different arguments
with same types that do different things" one (which is something Java
programmers have been dealing with for almost 20 years now, it's really not
that big a deal).
IMO your proposed cure is worse than the disease. :)
> Change generated constructors so that application code evolves better
> ---------------------------------------------------------------------
>
> Key: THRIFT-529
> URL: https://issues.apache.org/jira/browse/THRIFT-529
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java)
> Reporter: Nathan Marz
> Assignee: Bryan Duxbury
> Priority: Minor
> Fix For: 0.2
>
> Attachments: 529-revert.patch, thrift-529-v2.patch, thrift-529.patch
>
>
> The constructors generated by the Java compiler encourage code that breaks
> when the thrift definition changes. For example, it is common to add an
> optional field to a pre-existing schema, like:
> struct Activity {
> 1: required i32 id;
> 2: required i32 type;
> 3: optional i64 timestamp; //newly added
> }
> Any code that used the Activity(int, int) constructor will now break.
> One option to address this problem is to only generate empty constructors.
> However, this makes it cumbersome to create new objects as a line of code is
> needed to instantiate each field. A second option is to generate constructors
> only for required fields. For example, to create an Activity with a
> timestamp, the user would need to do the following:
> Activity a = new Acitivity(3,4);
> a.set_timestamp(timestamp);
> This gracefully handles the addition of optional fields. For the case of
> adding a new required field, the constructors would break. Arguably this is
> desired behavior since all the code would need to be updated anyway, and this
> way you would be getting compile errors instead of runtime validation errors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
