[ 
https://issues.apache.org/jira/browse/THRIFT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637769#action_12637769
 ] 

David Reiss commented on THRIFT-139:
------------------------------------

These are pretty cool features.

1/ There are two other places where get_key() is used.  Might as well replace 
those also.
2/ Is this going to generate some sort of unchecked cast warning because it 
casts containers to the plain type instead of a generic type (sorry, I'm not a 
Java generics expert.
3/ It seems like there is some repeated code due to the fact that there are two 
separate loops over the fields that do the same setup.  Do you think it would 
be possible to buffer up the getter and setter text in strings so that you 
could build them up concurrently before writing both of them to the output in 
order?  See render_const_value for the ostringstream technique.
4/ Most importantly, I think this generator assumes that beans mode is in use 
and won't compile without it (setFoobar is not defined in non-beans mode).


> Add reflection-like features to generated classes
> -------------------------------------------------
>
>                 Key: THRIFT-139
>                 URL: https://issues.apache.org/jira/browse/THRIFT-139
>             Project: Thrift
>          Issue Type: New Feature
>          Components: Compiler (Java)
>            Reporter: Bryan Duxbury
>            Assignee: Bryan Duxbury
>         Attachments: thrift-139.patch
>
>
> There are a few things I think would increase the usability of generated 
> classes:
>  * Contain named constants for each field name with its field ID. This would 
> allow you to do stuff like MyClass.SOME_FIELD_NAME and get the field ID and 
> use it elsewhere. (We use this as a selector for which field in a union-like 
> structure is selected.) You could also use the named constants in the 
> generated code's read and write methods to more clearly indicate which fields 
> are being read or written.
> * Setter and getter methods by field ID. You could have a signature like 
> "public object getFieldValue(int fieldID)" and "public void setFieldValue(int 
> fieldID, Object value)". This would allow you to write code that was generic 
> over different fields of the same type and only took the field ID as a 
> parameter, for instance. 
> Would other people be interested in capabilities like this? I'm sure we can 
> think of other things we'd like to add as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to