[
https://issues.apache.org/jira/browse/THRIFT-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786105#action_12786105
]
Todd Lipcon commented on THRIFT-529:
------------------------------------
bq. which is something Java programmers have been dealing with for almost 20
years now, it's really not that big a deal
Yes, ways like static factory methods. See Effective Java item #1 ("Consider
static factory methods instead of constructors")
Also #40 ("Long sequences of identically typed parameters are especially
harmful.")
#2 is also relevant ("Consider a builder when faced with many constructor
parameters")
> 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.
