request: Unmodifiable Attribute (Collections)

[evisentin]

There is a feature which I would find very useful, consider the class:

import lombok.AccessLevel;
import lombok.Getter;
import lombok.Setter;
import java.util.*;

public class MyClass {

  @Getter @Immutable private List myList = new ArrayList();
 
}

The getter generated with @Immutable should then return a Collections.unmodifiableList(myList )

PS; same for Collections, Set, Map and so on

what is your opinion?

PS: of course in the sample class there is no code to populate the list, let out for clarity

Thanks

[Peter Jernei]

We would also use this feature, It would support encapsulation better, even if the items in the collection are still modifiable.

And there would be 1 more usefuly annotation that marked the collection field to set it to empty in case null passed to the setter.

So the generated code should look like:

private List<OtherData> otherDataList = Collections.emptyList();


public List<OtherData> getOtherDataList(){
    return Collections.unmodifiableList(otherDataList);
}


public void setOtherDataList(final List<OtherData> otherDataList) {
    if (otherDataList == null){
        this.otherDataList = Collections.emptyList();
    } else {
        this.otherDataList = new ArrayList<>(otherDataList);
    }
}

[Reinier Zwitserloot]

We can't accept this idea; @Immutable suggests the field is immutable. What your proposal suggests this feature do, makes no sense if the list is itself immutable (if it is immutable, just return it). If the annotation is called @ReturnWrappedUnmodifiable, it would make more sense.

It also has an effect ONLY on the getter, but the annotation doesn't make that clear either, so, even better: @Getter(returnWrappedInUnmodifiable = true) would be better.

Unfortunately, you're only reducing a little bit of boilerplate here, it should be rarely applicable (how often do you have mutable lists which should be returned as wrapped unmodifiables? Half the time you want to return immutable copies, other times you want to return the actual list, modifiable and all, most of the time you want the data type itself to hold only immutable types, at which point you can just return it as is, as it's unmodifiable already)... and thus it fails afoul of the 'feature growth' rule: If we add this, I can think of about 45 other things @Getter should have (such as returnImmutableCopy, returnCopy, replaceNullWithEmpty, and I'm sure if we ask the greater lombok community we'll find 40 others)...

so, we have two options:

1) We don't implement this, or,

2) @Getter will end up having some 40-odd parameter options, and the documentation page for Getter grows from its current ~1 pager to ~5 pages.

I'm quite convinced #1 is the right way to go. But as always feel free to raise points that change the math here.

The same line of reasoning goes for the idea to have the setter replace null with 'empty' values, but to a lesser extent (I can't quite imagine as much here). However, it's even less applicable: Why not just @NonNull the field and throw an NPE if someone tries to set null? You'll find the bug immediately and you can now fix the caller; the caller should call .set(ImmutableList.of()), not .set(null).

Note, just having an annotation or setter param that says 'replace with empty' is no good!

What's the 'empty' variant of string? That's easy; "", we all know that.

But:

* Given that lombok does not support resolution for @Getter, how do we know what the empty value is for a type that isn't hardcoded into lombok? Let's say you have ComplexNumber in some third party math library, how do you configure things such that .setComplexNumber(null) ends up setting the field to new ComplexNumber(0, 0)? This is non-trivial, so either we leave the feature badly underspecced, or we make it incredibly complicated, and this isn't the kind of boilerplate busting that allows for either. Given that the value is so low, the implementation of this feature must be clean and easy and if that's not on the cards I'm pretty sure the right answer is to not have the feature in the first place.

* What's the empty variant of Integer? Integer.valueOf(0)? Probably, but my point is: This is not black and white; this is shades of gray. What's the empty variant of List? Collections.emptyList(), or new ArrayList<T>(), or even new ArrayList<T>(0)? They're all quite different and I find all 3 reasonable answers, so how would someone casually inspecting the code know what lombok is going to do without perusing the documentation in detail (which is a bad thing; the best features are so self-documenting and self-evident, your first gut instinct is right and feels right).

TL;DR: These feature requests do not clear the 'value for the money' bar, where value = how much boilerplate it removes and how often you'd need it, and 'money' = obviousness and maintainability.

On Monday, January 15, 2018 at 2:15:56 PM UTC+1, evisentin wrote: