[
https://issues.apache.org/jira/browse/THRIFT-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053549#comment-13053549
]
Eric Rannaud commented on THRIFT-627:
-------------------------------------
Should this change really uppercase the first letter of the field name in the
setter method name? This is really quite awkward for anyone not using camelCase.
struct T {
1: optional i32 some_field;
2: optional i32 max_element_speed;
}
Gives the strangely named methods:
t.__setSome_field(1);
t.__setMax_element_speed(200);
In particular, this breaks case-sensitive search (camelCase users generally
have to rely on case-insensitive search, as it's quite common to have the
"same" identifier show up in the form "camelCase" and "setCamelCase"; but if
you're used to a different style, you *expect* case to be preserved -- when
looking for "some_name", you're not in general looking for SOME_NAME, which
would likely be a macro or a constant).
vim(1), less(1), grep(1) all default to case-sensitive (and "grep -i" is a lot
slower than default grep).
Thrift had so far managed to not interfere much with the user's coding style,
is there a way to continue doing that?
I attached a thrift-627-no-cap-name.patch to generate the names:
::__set_some_field();
::__set_max_element_speed();
::__set_someField();
::__set_camelCaseName();
This is of course not ideal for developers used to writing setCamelCaseName(),
but I'd argue this would be a better compromise than the current choice.
Thanks.
> should c++ have setters for optional fields?
> --------------------------------------------
>
> Key: THRIFT-627
> URL: https://issues.apache.org/jira/browse/THRIFT-627
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
> Environment: c++
> Reporter: Ben Taitelbaum
> Assignee: Jake Farrell
> Fix For: 0.7
>
> Attachments: thrift-627.patch, thrift-627.patch,
> thrift-627_0.5.x.patch, thrift-627_trunk.patch
>
>
> It seems non-intuitive to me to have to set __isset.someField = true after
> setting an optional field someField on a struct. Would it make sense to have
> a set_someField method that would both set the field and modify __isset?
> One of the cases for this is for when a field goes from being required to
> being optional, and it's easy to forget to set __isset in the code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
