[jira] [Commented] (THRIFT-627) should c++ have setters for optional fields?

["Eric Rannaud (JIRA)" <ji...@apache.org>]

    [ 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