[
https://issues.apache.org/jira/browse/THRIFT-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786129#action_12786129
]
Jonathan Ellis commented on THRIFT-529:
---------------------------------------
I suspect that if "create a factory method for every possible combination of
optional parameters" were a common practice, Bloch would have mentioned that as
an antipattern, but it isn't, to my knowledge.
But debating style is obscuring the fundamental issue here, which is Not
Breaking Code You Don't Have To.
> 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.
