Add @Data.NoGetter and @Data.NoSetter Annotations and behavior

[lombokissues]

Migrated from Google Code (issue 37)

[lombokissues]

👤 gerhard.balthasar   🕗 Aug 24, 2009 at 18:24 UTC

As discussed here:
http://groups.google.com/group/project-lombok/browse_thread/thread/e5f70d48848e109a

Excerpts:

@ Getter and @ Setter

• You may create @ NoSetter and @ NoGetter annotations, this would help
  a lot for @ Data

---

Eh. Feels like too many annotations to me. I could extend AccessLevel
to include .DONTGENERATE but that's even worse (nothing is not an
access level, of course). It's a problem though. Is there a way out of
this that's nicer? Perhaps add exclude="" to @ Data itself. The reason
lombok doesn't cater to these situations is that it's not what lombok
was for. Any class with transient fields is probably well beyond the
level of 'trivial little structy class' which is what @ Data was meant
for. So I'm not convinced lombok needs to cater to this case. How
often do you use transient fields? I can count on one hand how often
I've used them, and in all cases, @ Data wouldn't really fit for that
class.

---

BTW, working with EJBs and JaxB I have transient fields quite often.
Not that much but I need them now or then. But the point is: When
using @ Data my classes often have only a getter or a setter for a
field. Especially for Lists/Maps, etc. the above mentioned 'immutable'
attribute would be enough, but for any other field type I need a way
to avoid the creation of a setter/getter. I really think, Lombok
should handle this case. But I agree with you:

• Adding an exclude list on @ Data would not be enough, because you
  would need a list for getters and for setter. Much typing. Bad.
• Extending AccessLevel is bad also, I agree.
• @ NoSetter/@ NoGetter, which are additional annotaion with no other
  value left. Also bad.
• Transient fields are neither a good way, although lombok already
  reacts on them when using @ EqualsAndHashCode. But extending this to
  @ Getter/@ Setter would prevent Setter/Getter method creation and

normaly transient fields need access methods also.

Conclusion: Bad. What's left then?

Changing the behaviour of @ Datas Setter/Getter creation would be an
option:

• Create Setter and Getter if neither @ Setter nor @ Getter is annotated
  at a field or @ Setter and @ Getter are both anotated
• Create only Setter if @ Setter is annotated
• Create only Getter if @ Getter is annotated

In other words: create only the method type that is declared, but
default to both annotations declared, if not annotated. No additional
clutter but again, the behavoir is simple declared by the annoations
the developer writes down. I think this can be considered a logical
behavior in my eyes and easy to understand.

Would this solve the problem?

---

It might be acceptable if @ NoSetter and @ NoGetter become sub-
annotations of @ Data. So:

public @ interface Data {
public @ interface NoSetter {}
public @ interface NoGetter {}

}

That seems a fair compromise between sticking too much crud in the
lombok package and offering this flexibility, which does have its
place. File a ticket for it?

---

Yes, sure, it's a good compromise. Ticket is on in some minutes.

So we will get this situations with @ Data and a field foo:

• I want public setter and getter: No additional annotation neccessary
• I want a protected setter but a public getter:

@ Setter(AccessLevel.PROTECTED) private Object foo;

• I want no setter, but a getter:

@ NoGetter private Object foo;

• I want no accessors at all:

@ NoSetter @ NoGetter private Object foo;

Seems acceptable for me, it's just a decent declarative clutter,
because if you are using @ Data, you have mostly accessable fields and
in the last case, not too much clutter is produced. But the "I want no
accessors at all" brings me back to my previous two solutions:

• If transient fields would be ignored, no Annotations were needed for
  this case
• Changing the behavior of Getter/SEtter creation would not help at
  all

So, if you're not convinced by the transient field solution, I'll go
with your proposal too.

[lombokissues]

👤 reinierz   🕗 Sep 01, 2009 at 22:58 UTC

[lombokissues]

👤 r.spilker   🕗 Sep 02, 2009 at 08:33 UTC

If we implement NoGetter and NoSetter as an annotation, we also need to check when
you use it without @ Data on the class. And we should handle the case when both
@ Getter and @ NoGetter are specified.

Introducing a AccesLevel.DONTGENERATE (or AccessLevel.NONE) would solve this problem.
So would extending @ Data with one or two extra parameters that accept an array of
field names.

I'm not particular fond of either.

[lombokissues]

👤 reinierz   🕗 Sep 03, 2009 at 00:24 UTC

Added in commit b262ed9 and will be rolled out in v0.8.5.

We've decided to go with a new accesslevel instead, so:

@ Data public class Foo {
@ Setter(AccessLevel.NONE) int x;
}

this was waaay simpler than adding new annotations, and there's a (admittedly somewhat tedious) argument
to be made that 'NONE' is simply an extreme access level (extremely private?). But mostly the simple.

[lombokissues]

👤 reinierz   🕗 Oct 16, 2009 at 08:54 UTC

[lombokissues]

End of migration