Lombok: @Getter and @Setter together in one annotation

[igor-dmitriev]

Hi. I and my collegues think that it will be more convinient to use just one annotation instead of
two - @Getter and @Setter. Take a look :
before :

class User {
 @Getter
 @Setter
 private String name;
}

after :

class User {

 @GetterSetter or @GetterAndSetter or smth like that
 private String name;
}

In the second case we have just 1 line code instead of 2 lines

[Maaartinus]

You can save another one by writing

@Getter @Setter private String name;

or even more with

@Getter @Setter private String name, street, town, state, country, planet, galaxy;

Just kidding with the second example, but the first one is what I do. Even with my compact style, the combined annotation could be useful for things like

@GetterSetter(AccessLevel.PROTECTED)

[tafit3]

Instead of naming it @GetterSetter, how about @Accessors? The annotation is already taken, but still experimental, so maybe the functionality could be changed a little bit, so that specifying @Accessors might mean not only configuring style of getters and setters, but also adding them by default?

@Accessors
public class AccessorsExample {
   private final String name;
   private int age;
}

public class AccessorsExample {
   @Setter
   private String name;
   @Accessors
   private int age;
}

Other names do not fit so well:

@Accessor
@Accessible
@Attribute
@Encapsulated
@Etters
@Mutators
@Property

[dargiri]

I've proposed pull request: https://github.com/rzwitserloot/lombok/pull/1075 but seems that it's ignored :(

[maximebochon]

If I'm not mistaken, "accessor" and "mutator" are the theoretical terms for respectively "getter" and "setter", so we cannot use one term for both of them.

"Etters" is a funny proposal but I like it and it does not already mean something in English.

[shalugin]

It's a really very convenient feature!

[gwokudasam]

I second having one like @GetterSetter(AccessLevel.PROTECTED)

[ErrorsAndGlitches]

+1 for @etters

[igor-dmitriev]

@rzwitserloot @rspilker hey guys, what do you think about this?

[claudio-rosati]

+1
I've proposed #1614

[gmullerb]

If lombok annotations allow the target ElementType.ANNOTATION_TYPE , then we can combine any lombok annotation and give what ever name we want.

E.G.:

1. new lombok annotations:

@Target({ElementType.FIELD, ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.SOURCE)
public @interface Setter { 
...

@Target({ElementType.FIELD, ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.SOURCE)
public @interface Getter { 
...



md5-4ca71be28de55498be8bd3a3d64ae16c



@Getter
@Setter
@ToString
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.SOURCE)
public @interface SomeName {
}

I think "issue" https://github.com/rzwitserloot/lombok/issues/1901 requested something similar but with an ambiguous/confusing explanation.

[rzwitserloot]

As a rule, lombok does not cater to broken style guides.

@GetterSetter saves you a single character over @Getter @Setter and is therefore ridiculous. Now, bring in style guides and all of a sudden you may be looking at 'saving you' an entire line of code.

The solution is to fix your style guide, not to ask us to add a second way to accomplish the same thing. We are strong believers in not introducing multiple ways to do the same thing unless there is a really good reason for it, and 'well, my style guide enforces all annotations to appear on their own line, therefore, this saves me a line' is not a good enough reason.

I get that @GetterSetter(AccessLevel.PROTECTED) saves a lot more, but how often do you want non-public, and the same access level on BOTH the getter AND the setter? Sure, it happens, but, far too rare to cater to it.

[carlislefox]

Sorry, I'm not sure what you are saying here - the case of wanting a getter and setter on a field but not wanting equals or hash overridden on the object is too rare a case to cater for specifically?

How are we judging the rarity of cases here? I work on the back end data systems for a large multi-national retailer and this is extremely common. The vast majority of our services have a lot of model objects with both @Getter and @Setter annotations, is a shorthand annotation to provide both really pushing LOMBOK's syntax too far into obscurity?

I'm not sure where style guides come into this either, it is just visually annoying to have two annotations over a lot of fields. Where style guides (such as checkstyle) _will_ bite you in the ass is if you try and reduce the amount of vertical annotation clutter as usually they are configured (at least in my experience) to fail the build should something like two annotations on a single line be detected.

Being able to set a field as gettable and settable with one annotation makes sense to me. Being able to set all the fields on a class as gettable and settable (without overriding equals or hashcode) also makes sense to me.

Who knows, maybe I am crazy.

[randakar]

No, you're not crazy, We're seeing this a lot in model objects too.
@Data goes a long way but having annotations composable would help.
However, that is not that easy apparently.

That being said, moving to immutable objects (in dto's, in the model, in
everything, really) removes all of the setters, making this incarnation of
the problem go away. And immutable objects help with more than just
reducing annotation clutter..

On Wed, Jan 15, 2020 at 2:27 PM Liam Stewart [e-mail]
wrote:

Sorry, I'm not sure what you are saying here - the case of wanting a
getter and setter on a field but not wanting equals or hash overridden on
the object is too rare a case to cater for specifically?

How are we judging the rarity of cases here? I work on the back end data
systems for a large multi-national retailer and this is extremely common.
The vast majority of our services have a lot of model objects with both
@getter https://github.com/getter and @Setter
https://github.com/Setter annotations, is a shorthand annotation to
provide both really pushing LOMBOK's syntax too far into obscurity?

I'm not sure where style guides come into this either, it is just visually
annoying to have two annotations over a lot of fields. Where style guides
(such as checkstyle) will bite you in the ass is if you try and reduce
the amount of vertical annotation clutter as usually they are configured
(at least in my experience) to fail the build should something like two
annotations on a single line be detected.

Being able to set a field as gettable and settable with one annotation
makes sense to me. Being able to set all the fields on a class as gettable
and settable (without overriding equals or hashcode) also makes sense to me.

Who knows, maybe I am crazy.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1052?email_source=notifications&email_token=AABIERJ6TWNQCTC3IJ3S4RTQ54FL3A5CNFSM4B6LCQD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAJTEY#issuecomment-574658963,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABIEROUB3MOYBC5LAKA7NTQ54FL3ANCNFSM4B6LCQDQ
.

--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven

[Maaartinus]

@carlislefox

I honestly don't understand the controversy over this suggestion... I feel like "I want to add getters and setters to some stuff without boilerplate" was like the first thing that popped into the original authors head?

Unfortunately, there are too many useful shortcuts. That's why IMHO none of them should be implemented. Instead of that, a general solution should be found. There was a proposal using annotated annotations, which was shot down by the project owners (as they consider it to be ugly) and also by reality (it's not doable in Lombok due to needing resolution). There's another proposal using lombok.config, which AFAIK may work well. Let's concentrate on it....

[rzwitserloot]

Given that you gave no proof your 'extremely common' statement other than your word that you work for a 'large' 'multi-national' retailer, apparently we're judging by mere say so and no proof whatsoever.

I say it's rare. There. That'll assuage any doubts.

@carlislefox: is a shorthand annotation to provide both really pushing LOMBOK's syntax too far into obscurity?

No. I never said that was the problem, I said: It saves you 2 characters relative to @Getter @Setter. _ALL_ lombok features are judged by weighing the benefits against the cost. The benefits are: "Saves 2 characters", thus, the cost has to be near nil. The costs are not near nil. They aren't particularly large, but large enough to outweigh 'saves 2 characters'.

@carlislefox: How are we judging the rarity of cases here? I work on the back end data systems for a large multi-national retailer and this is extremely common.

@carlislefox: I'm not sure where style guides come into this either, it is just visually annoying to have two annotations over a lot of fields.

I do not understand how @GetterSetter is fine, but @Getter @Setter is 'visually annoying', unless you smear your @Getter @Setter out over two lines. The easy solution is to therefore just not do that - do not smear it out over two lines. The only argument I can think of against the advice "Just put those on a single line", is: "But my style guide does not let me", which is where the style guide comment came in. If you are not labouring under the dictatorial decree of a style guide that enforces you to multi-line this, we're back to: Okay, so, @Getter @Setter is visually noisy but @GetterSetter is not. We're down to opinion, my opinion as core contributor matters more, and if that's the argument, it's vetoed here and now and no amount of 'but I think so' is going to change that opinion. Some other argument based on falsifiable information or logical reasoning will need to be provided (hint: "I work for a large multi-national and I think so" is barely falsifiable, and even if it was, is not pertinent. Popularity contest arguments only work if start with: "I wrote a spider that scanned every java project on github, and it says that of all projects that use lombok in the first place, 80% of them use @Getter and @Setter in combination at least 10 times" or whatnot. Yes, that will require some work. If you want to appeak to popularity , __that is the only popularity appeal we accept__.

@carlislefox: that it has no easy way to guarantee a collection is instantiated (and is not immutable) when built without explicitly being set just seems absolutely bonkers to me.

This is completely irrelevant to a discussion about combining @Getter and @Setter. Yeah, I think you need to go feed some ducks and cool off, geez.

[rzwitserloot]

Had to delete a bunch of completely irrelevant borderline insulting speculation by @randakar, unfortunately.

[rzwitserloot]

This issue has no hope of making it. However, all who want this may want to read up on #2294 which sort of gets you what we want, were we to implement this.