[
https://issues.apache.org/jira/browse/THRIFT-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786034#action_12786034
]
David Reiss commented on THRIFT-529:
------------------------------------
I'm still not in love with the sarcasm or excessive negativity. I'll just
point a few things out.
1/ I didn't veto anything, and this has nothing to do with C++. I think it is
a bad idea for us to generate code in a way that causes semantics to silently
change when a new optional field is added. This in dangerous in the long term.
2/ I have no problem reverting this change.
3/ Restoring the old constructor and marking in deprecated is probably a good
idea.
> 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: 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.
