@Construct annotation
Jean-Philippe Toupin
I would like to first thank you for this wonderful project.
I have like many others been frustrated with getters and setters and
Lombok solves that problem the same way I would have liked JDK 7 to
solve it. This project will save valuable time to many developpers.
Second, I would like to suggest a new annotation @Construct. When a
field is annotated with @Construct, Lombok would create a constructor
with that field even though it is not marked as non-null.
ie:
@Data
public class User {
@Construct
private String username;
@Construct
private String email;
private String password;
}
Then:
User user = new User("username", "email");
Sometimes you want nullable fields to be part of the constructor to
ease unit testing.
Thanks,
Bogdan Marian
You have a very interesting suggestion, but I do have a question: how do you create different constructors based on different fields combination ? Based on your example, how would Lombok be able to create a ctor using just the userName and another using both userName and email?
I would suggest to add some attributes to the @Construct annotation in order to specify to which ctor the field will be apply to, something like:
@Data
public class User {
@Construct(appearsIn={"ctor1", "ctor2"})
private String username;
@Construct(appearsIn={"ctor2"})
private String email;
private String password;
}
User(string username){
...
}
and
User(String username, String password){
...
}
The "appearsIn" (or whatever the attribute name is) should allow the Lombok user to specify the list of parameters each ctor should have.
Also, there is another issue: how can we tell the order of the field inside the ctor parameter list ?
The simplest solution I can think of right now, is to use composite annotations, each annotation representing a ctor with two elements: the key to group different fields for a ctor and their index in the param list - somethign like:
@Construct(appearsIn={@Ctor(name="ctor1", index = 1), @Ctor(name="ctor2", index=2)})
private String username;
@Construct(appearsIn={@Ctor(name="ctor2", index=1)})
private String password
The generated ctors would looke like:
User(String username){
...
}
User(String password, String username){
...
}
So, to add @Construct annotation does imply some "heavy stuff" ... :)
--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/
To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to
project-lombo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/project-lombok?hl=en
Reinier Zwitserloot
object construction.
Roel and I agree that the way @Data works with constructors is sub-
optimal, we just need to find some time to sit down and sketch out a
good alternative. A few things I'm virtually positive of, though:
1. We will not be offering ways to swap the order of things. The order
is the same order as the fields in the file. If you want a different
order, flip the fields. If you want one constructor with one order,
and another with another, write them out.
2. We will not be using names for constructors; that seems rather
silly as constructors don't have names. We also strongly dislike
overloading, which extends to constructors. If we are going to allow
any overloading at all, it would be just 2 constructors: the normal
one, and an empty one, because loads of tools need an empty
constructor (serialization in certain situations, as well as
hibernate, SPI, and more).
I'm going to guess that what we'll come up with will look something
like an explicit @FieldConstructor or some such that tells lombok to
generate 1 constructor based on the fields, regardless of any existing
annotations, and probably using either an optional listing of field
names on that annotation, or @FieldConstructor.Include annotations on
the fields you want.
Regardless of what it'll look like, we hear you - the current
constructor building strategy used by @Data sucks :P
We'll post a plan before working on an implementation so you and the
other heroes of the project-lombok group can tear it to pieces, of
course!
> On Mon, Dec 21, 2009 at 2:49 AM, Jean-Philippe Toupin <jptou...@gmail.com>wrote:
>
>
>
> > Hello,
> > I would like to first thank you for this wonderful project.
>
> > I have like many others been frustrated with getters and setters and
> > Lombok solves that problem the same way I would have liked JDK 7 to
> > solve it. This project will save valuable time to many developpers.
>
> > Second, I would like to suggest a new annotation @Construct. When a
> > field is annotated with @Construct, Lombok would create a constructor
> > with that field even though it is not marked as non-null.
>
> > ie:
>
> > @Data
> > public class User {
>
> > @Construct
> > private String username;
>
> > @Construct
> > private String email;
>
> > private String password;
>
> > }
>
> > Then:
>
> > User user = new User("username", "email");
>
> > Sometimes you want nullable fields to be part of the constructor to
> > ease unit testing.
>
> > Thanks,
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups group forhttp://projectlombok.org/
>
> > To post to this group, send email to project...@googlegroups.com
> > To unsubscribe from this group, send email to
> > project-lombo...@googlegroups.com<project-lombok%2Bunsubscribe@go oglegroups.com>