[
https://issues.apache.org/jira/browse/THRIFT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637784#action_12637784
]
Bryan Duxbury commented on THRIFT-139:
--------------------------------------
1/ yes, makes sense, will look into it.
2/ it won't generate warnings, because a Set<Integer> is also a Set, but I'll
fix this to use type_name() correctly anyways, since the information is there.
(I'm still learning all the existing features of the Java generator... :)
3/ will check this out
4/ Not to totally hijack this issue, but perhaps there shouldn't be a non-beans
Java generator. The reason that I'm so into the beans generator is that,
frankly, the non-beans generator did not work as it needed to. I understand the
argument that there was a desire for especially lightweight generated code, but
it sacrifices a lot of other elements, like __isset consistency and thus wire
density, which seems to be a critical element. We could simplify the generator
if we didn't need to support two different modes at all times, which would be
nice, and then this wouldn't be an issue at all. I can see what it would take
for this patch to work with the generator remaining the same, though.
> 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.
