Can array filed setter like T...

[manbusky]

@Data

class Department {

     Members[] members;

     ...

}

setMembers(new Members[] {member1, member2, member3});

change to 

setMembers(member1, member2, member3);

it could be much more gracefully!

 

[Aasif Khan]

is there some progress on this one?

[Reinier Zwitserloot]

Arrays are low-level things that do not have nice API and never will. There does not seem to be much point to attempting to deliver on this. In fact, we would actively reject such a feature. We hold the following view:

* If lombok has a boilerplate busting feature, then pretty much by definition the lombok dev team is saying that this code is boilerplate, as in, it is common.

* Whilst that's not actually an airtight logical loop, that strongly insinuates that it's good code. Or at least not an active code smell.

* Therefore, we do not ever write features for code that is 95%+ of the time a code smell.

And what you propose is ugly as all get out. Arrays do not make nice API and never will. Letting callers publicly set it, is bizarre. You have no control over where that array came from, anybody can change fields of it, it doesn't have nice toString behaviour, and so on. API design is black and white: Either you make the nicest API you can, or, performance trumps API design and there is no further point in discussing this. So, assuming you want nice API, then right answers look like making that a `List<Member>` instead, or, the 'setter' copies, to avoid the problem of now having an array that external parties can modify without your code knowing about it (and if that's okay, then why have a setter? Just make that field public!). But, 'the setter actually clones the array' is quite the leap, that would be an entirely new feature, and almost nobody uses arrays like this, given that their API is so sucky (equals/hashCode don't do the right thing, toString is useless, can't control mutability, and yet can't be grown or shrunk either, giving you the worst of both worlds, and you can't fix that or add methods to it). So, not boilerplate, thus, not a good idea for lombok.

In a word: No, and we would reject PRs.

[Chris Becker]

Why not simply implement the @Data generated methods to accept vararg arrays generally?

As those generated methods do not have multiple different parameters, simply excanging T[] with T... and same for all primitives (int[] -> int... etc) should not be a problem, right?

Or is this some implicit trick with explicit checks to prevent heap pollution?

@Data

class Department {

     Members[] members;

     ...

      // lombok generated

      public void setMembers(Members[] pMembers) {

           members = pMembers;

      }

      // suggested

      public void setMembers(Members... pMembers) {

           members = pMembers;

      }

}

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/41744930-51e1-4e6c-b66d-f39074099de6n%40googlegroups.com.

--

Christian Becker
+49.176.2238 9755
chris.b...@gmail.com