Feature Request: Custom getter/setter method name generation

[MS]

The @Getter and @Setter annotation are really useful, I use them all the time and they really help to keep my classes lean.  I would be really nice if there was a way to customize the name of the method that is generated.  The @Accessors annotation already allows using fluent=true to remove the "get" and "set" prefix.  I would like to see something that allows the user to customize that prefix also.  For example:

 

@Getter @Setter @Accessors(getMethodPrefix="somePrefix", setMethodPrefix="aDifferentPrefix")

int myInt;

 

Would generate:

 

public int somePrefixMyInt() {

    return myInt;

}

 

public void aDifferentPrefix(int myInt) {

    this.myInt = myInt;

}

 

If not defined, the default for getMethodPrefix would be "get", and the default for setMethodPrefix would be "set".

 

 

Thanks and keep up the good work!

[Reinier Zwitserloot]

What's the use case for this? It's not exactly hard to do, but any addition has a cost associated with it - the need to support the feature (no matter how simple it is), and the extra documentation and 'API burden'. The mere fact that this option exists means that users need to read about it when they hit auto-complete on their parameters of @Getter and @Setter.

I have never seen any getter/setter use 'in the wild' that wasn't either getX, setX, isX, or just 'x'. But then, I do most of my work on small teams so I haven't seen all that much, I might be missing something.

 --Reinier Zwitserloot

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[MS]

There might be other use cases also, but I would like to have this feature to be able to easily create custom builders (using a "with" prefix).  I have seen the new @Builder annotation in version 0.12, but there are situations where custom methods in a builder are necessary and @Builder does not provide for that.  For example, in one builder that I recently wrote, I needed to have a method that took a varargs argument to populate an array.  There is no way to do that with @Builder, so I would have to create the builder myself.  It would be easier to create the builder if I could use @Setter to generate all the setters (and then just add my custom method).  The project I work on uses "with" as the prefix for builder setters, so that is why I would like to have this feature.

 

Thanks!

[Fabrizio Giudici]

On Thu, 25 Jul 2013 16:25:05 +0200, MS <markst...@gmail.com> wrote:

> There might be other use cases also, but I would like to have this
> feature
> to be able to easily create custom builders (using a "with" prefix). I
> have seen the new @Builder annotation in version 0.12, but there are
> situations where custom methods in a builder are necessary and @Builder
> does not provide for that. For example, in one builder that I recently
> wrote, I needed to have a method that took a varargs argument to populate
> an array. There is no way to do that with @Builder, so I would have to
> create the builder myself. It would be easier to create the builder if I
> could use @Setter to generate all the setters (and then just add my
> custom
> method). The project I work on uses "with" as the prefix for builder
> setters, so that is why I would like to have this feature.

Doesn't @Wither help?

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[Reinier Zwitserloot]

'with' as a prefix for something that actually does what 'set' does? That sounds like an accident waiting to happen. 'withX' means, by convention, that you get a __clone__ back, except with the one field you are setting updated to this new value. If withX actually changes _this_ object and then returns self (which methods in builders normally do), you're sitting on a powderkeg.

 --Reinier Zwitserloot

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.

To unsubscribe from this group and stop receiving emails from it, send an email to project-lombok+unsubscribe@googlegroups.com.

[MS]

I am sorry but I have never heard of any "convention" where 'withX' means that you get a clone back. There is no formal convention for builder patterns, but many that I have seen do use with instead of just the field name.  For example, see http://www.stuartgunter.org/fluent-bean-definition-spring/ and http://martinfowler.com/bliki/FluentInterface.html. In my organization, we use the "with" prefix for builder pattern "setters".  I find it useful when using autocomplete so that you can just type with and then see only the methods you are looking for.

I don't like @Wither for this use case, because it does something else (namely, creates a copy instead of modifying the original builder)

 --Reinier Zwitserloot

To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.

[Martin Grajcar]

On Fri, Jul 26, 2013 at 4:34 AM, MS <markst...@gmail.com> wrote:

I am sorry but I have never heard of any "convention" where 'withX' means that you get a clone back. There is no formal convention for builder patterns, but many that I have seen do use with instead of just the field name.  For example, see http://www.stuartgunter.org/fluent-bean-definition-spring/ and http://martinfowler.com/bliki/FluentInterface.html.

You got it perfectly wrong in the first link. The joda DateTime obviously uses withers:

http://joda-time.sourceforge.net/apidocs/org/joda/time/DateTime.html#withYear(int)

Concerning the second one, it really looks like sort of setter, but here is "with" not used as a prefix.

In my organization, we use the "with" prefix for builder pattern "setters".

Is it a legitimate reason to quit? :D

 

I find it useful when using autocomplete so that you can just type with and then see only the methods you are looking for.

A typical Builder has hardly any methods except for build(), setters and methods inherited from Object (actually, public clone() is quite useful). So I would gladly exchange such autocomplete advantage for shorter names.

But how does using "with" instead of "set" help???

[Reinier Zwitserloot]

Given that lombok's @Wither sticks with the 'withX implies a clone' concept, this is still a pretty bad idea because of the confusion it would add. Builders do not have any methods other than build(), the standard batch you can't avoid from Object.class, and the relevant methods, so the penalty of not having a key word to autocomplete on isn't particularly relevant - and that can be addressed via using @Accessors(prefix = true) (then you get set as a prefix, not with).

The example in link 1 is actually using with as a clone-on-call - it's from jodatime, which uses the same convention as lombok does for what 'with' means: It means clones are being made. Later on in the article, the sentence "method prefix (defaults to with)" crops up, but this is referring to the prefix of clone-with-one-parameter-different methods on immutable classes such as jodatime's DateTime object. This is in fact proof that 'with' is very _inappropriate_ for builder-setters.

The example in link 2 uses an entirely different concept. Here 'with' is the _ENTIRE_ name of the method, obviously it can't be the empty string. This is not setting any kind of convention precedent for how to prefix builder methods. It's also not entirely clear to me if these 'with's are clone-based, or mod-and-return based. I can imagine they are clone based, which would again be further support that 'with' is not appropriate for builder setters.

The major example in the second link is also quite confusing: it's a bunch of with calls, with a random 'skippable()' thrown in, except this seems to either (A) oversimplify things and thus be buggy code, because how can you magically get the best of both worlds and have with() return the Order object when you want that, but return the OrderLine and let you call skippable() on this object when you want that? or (B) it's going overboard on the fluency concept, with Order itself gaining a skippable() method which configures the last added orderline to actually be skippable.

In either case, this example seems sufficiently ill-considered that I'm not sure it should serve as a basis for convention.

 --Reinier Zwitserloot

On Fri, Jul 26, 2013 at 4:34 AM, MS <markst...@gmail.com> wrote:

[MS]

I think that example 1 actually proves my point.  Although the example from JodaTime is obviously not a real builder pattern, the fact that the default method prefix of Stuart Gunter spring-beans library is "with" shows that many people do use "with for builders.  Here are some other articles that support this: http://gary-rowe.com/agilestack/2012/07/11/how-to-build-a-builder/, http://bloodredsun.com/2011/05/03/defence-builder-pattern/.

 

However, putting all that aside, I think this discussion is getting off-topic.  The original question was just to support custom getter and/or setter prefixes.  I gave one use case, but I am sure that there are other use cases also.

[Reinier Zwitserloot]

No, that 'with' prefix is specifically for 'how do I call clone-and-change methods on the underlying object' - it is specifically proof for the reverse.

I still haven't heard of a use case that isn't actively advocating for confusion (in light of the idea that lombok is trying to establish that 'with' means clone-and-change).

 --Reinier Zwitserloot

[jruhe]

public class Spec {
@Qualifier("stupidName") // Spring
@Setter("stupidName")
private String goodName;
}

That is my use-case.

Greetings,

Julian

[Aidanvii]

I also have a use case, albeit quite specific. 

I am working on a project that uses SWIG generated classes for calling native getters.

These getters use pascal case as it's part of our C++ coding standard, as well as C#.

I can't change this as it affects all supported platforms.

For the purpose of testing I would like to create simple 'mock' child classes of the generated SWIG wrapper classes with lombok's @Getter annotation for overriding the superclass getters (calls JNI functions and throws UnsatisfiedLinkError).

Obviously there are other mechanisms for creating stub objects, but they are not flexible enough for my needs.

I could also write my own getters, but unit testing is time consuming as it is, and I want to keep the mock classes as concise as possible.

if I could make the following:

@Getter private final int id; // some extra config obviously

generate the following

public int GetId()

{

   returin id;

}

That would be great.

[dslivka]

This is my use case (originally posted at https://github.com/rzwitserloot/lombok/issues/836):

One motivation would be customization of getter/setter names for field names starting with underscore. In my case, I need setter named setIF() for field protected String _if;. I do not want to rename the field (it was generated from XSD and Dozer relies on the name for mapping). CXF/JAXB generates seter setIF(), also Dozer seems to be relying on such getter/setter name. Customization of getter/setter name in Lombok would be the most elegant and easy-to-read solution. The field is also annotated with @XmlElementName(name = "IF"), maybe that's where JAXB got the getter/setter name from.

Dňa štvrtok, 25. júla 2013 7:28:36 UTC+2 Reinier Zwitserloot napísal(-a):