You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Bryan Duxbury (JIRA)" <ji...@apache.org> on 2010/03/30 23:10:27 UTC
[jira] Updated: (THRIFT-663) JavaBean code generator produces
incorrect setter methods
[ https://issues.apache.org/jira/browse/THRIFT-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury updated THRIFT-663:
---------------------------------
Attachment: thrift-663.patch
OK, how about this?
The "beans" option will make sure the setter methods return void.
The "private-members" option leaves the setter methods alone, but makes sure the actual members are private. This is for those of us who want the builder style setters but private instance variables.
Can you give it a whirl and see if it meets your needs?
> JavaBean code generator produces incorrect setter methods
> ---------------------------------------------------------
>
> Key: THRIFT-663
> URL: https://issues.apache.org/jira/browse/THRIFT-663
> Project: Thrift
> Issue Type: Bug
> Components: Compiler (Java)
> Affects Versions: 0.2
> Reporter: Dave Engberg
> Priority: Minor
> Attachments: java-setter.diff, thrift-663.patch
>
>
> The original Thrift JavaBean generator produced set* methods for a property 'foo' that looked like:
> public void setFoo(int foo) {
> this.foo = foo;
> }
> The more recent code in the 0.2.0 release now returns a value:
> public MyStruct setFoo(int foo) {
> this.foo = foo;
> return this;
> }
> I can imagine this was possibly desired by someone to implement a "chaining" style of coding, but this is no longer a correct JavaBean. The JavaBean spec requires that the return type of set* functions be 'void', and various tools and frameworks enforce this requirement. For example, the Stripes web UI toolkit thinks that a field is read-only if the set* function doesn't return 'void'.
> I'll attach a trivial patch to restore this to the previous behavior. If a chaining-style setter is desired by others, I'd recommend making this a separate method on the bean rather than replacing the standard setter. E.g.:
> public MyStruct setChainFoo(int foo) { ...
> Or something like that.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (THRIFT-663) JavaBean code generator produces
incorrect setter methods
Posted by Bryan Duxbury <br...@rapleaf.com>.
I'd be willing to explore this option. This is just a more incremental
approach, I'd say.
On Tue, Mar 30, 2010 at 2:20 PM, Mathias Herberts <
mathias.herberts@gmail.com> wrote:
> On Tue, Mar 30, 2010 at 23:10, Bryan Duxbury (JIRA) <ji...@apache.org>
> wrote:
> >
> > [
> https://issues.apache.org/jira/browse/THRIFT-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
> >
> > Bryan Duxbury updated THRIFT-663:
> > ---------------------------------
> >
> > Attachment: thrift-663.patch
> >
> > OK, how about this?
> >
> > The "beans" option will make sure the setter methods return void.
> >
> > The "private-members" option leaves the setter methods alone, but makes
> sure the actual members are private. This is for those of us who want the
> builder style setters but private instance variables.
>
> Why not come out all the way and have a 'builder' option which would
> create a Builder class which would do something similar as what J.
> Bloch describes in Effective Java (@see
>
> http://rwhansen.blogspot.com/2007/07/theres-builder-pattern-that-joshua.html
> )?
>
Re: [jira] Updated: (THRIFT-663) JavaBean code generator produces
incorrect setter methods
Posted by Mathias Herberts <ma...@gmail.com>.
On Tue, Mar 30, 2010 at 23:10, Bryan Duxbury (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/THRIFT-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Bryan Duxbury updated THRIFT-663:
> ---------------------------------
>
> Attachment: thrift-663.patch
>
> OK, how about this?
>
> The "beans" option will make sure the setter methods return void.
>
> The "private-members" option leaves the setter methods alone, but makes sure the actual members are private. This is for those of us who want the builder style setters but private instance variables.
Why not come out all the way and have a 'builder' option which would
create a Builder class which would do something similar as what J.
Bloch describes in Effective Java (@see
http://rwhansen.blogspot.com/2007/07/theres-builder-pattern-that-joshua.html)?