@Value instead of @Data ?

[Dan Haywood]

Hi all,
First time poster, just come across this project, looks very
interesting.

This might not be the right place to raise, but shouldn't
@EqualsAndHashCode (or perhaps even @Data) really be @Value. Adding a
hashCode and equals() is really saying the object has value semantics,
as per Bloch's effective java etc.

Perhaps the annotation it could also generate a serialVersionId as
well?

There are similarities with some of the stuff I've been doing with
(also open source) Naked Objects framework in terms of declaratively
defining semantics, so although Lombok's goal is rather wider and more
general purpose, I can think of a few of the annotations that we've
defined that might benefit from the Lombok treatment.

Is there somewhere else I should post any ideas though, or is this the
correct place?

Cheers
Dan Haywood

consultant, trainer, author - developing enterprise applications
blog: http://danhaywood.com
books: "Domain Driven Design using Naked Objects", http://pragprog.com/titles/dhnako

[Michael Lorton]

My $0.02.

1. @Value to me would imply a class with no setters: all observable aspects of the object are immutable.
2. Using an annotation to do serial id does not simplify the code (much), since setting the serial id is already one simple line.
3. Yes, this is the right place to post ideas like this.

M.

[Dan Haywood]

Michael Lorton wrote:

1. @Value to me would imply a class with no setters: all observable aspects of the object are immutable.

doh!  you are right, of course.  So, @Value could imply @Data minus @Setter ?

1. Using an annotation to do serial id does not simplify the code (much), since setting the serial id is already one simple line.

I wasn't suggesting an additional annotation, instead that @Value implied serialVersionId, (and implement java.io.Serializable too, I guess).

1. Yes, this is the right place to post ideas like this.

ok then.

Dan
http://danhaywood.com

[Michael Lorton]

On Sun, Sep 6, 2009 at 1:39 AM, Dan Haywood <dkha...@gmail.com> wrote:

Michael Lorton wrote:

1. @Value to me would imply a class with no setters: all observable aspects of the object are immutable.

doh!  you are right, of course.  So, @Value could imply @Data minus @Setter ?

If you declare all your instance variables as final, @Data will do the right thing --

@Data class Point {
   final int x;
   final int y;
}

is equivalent to

class Point {
   final int x;
   final int y;
   Point(int x, int y) { this.x = x; this.y = y;
   public int getX() { return x; }
   public int getY() { return Y; }
}

There might be some case that @Data wouldn't catch, where there was some internal state and or hidden calculation, but it would be unusual.

M.


 

[Dan Haywood]

Michael Lorton wrote:
>
> If you declare all your instance variables as final, @Data will do the
> right thing --
>
> @Data class Point {
> final int x;
> final int y;
> }
>
> is equivalent to
>
> class Point {
> final int x;
> final int y;
> Point(int x, int y) { this.x = x; this.y = y;
> public int getX() { return x; }
> public int getY() { return Y; }
> }
>

Hmm, I guess you could argue it both ways, and maybe it's just down to
personal preference. For myself, rather than infer value semantics from
the presence of the 'final' modifier, I'd rather omit the final modifier
and just say that the class is a value.

That is, I'd rather write:

@Value class Point {
int x;
int y;
}

(which would also implement java.io.Serializable).

Reinier & Roel:
perhaps projectlombok.org could have a place to register these ideas so
that the community could vote on them?

Dan

[Michael Lorton]

@Value , meaning all instance variables are made final and a constructor and all getters are generated, seems like a useful tag. 

Dunno what kind of priority it should get.  Definitely somewhere behind my own requests for @Mock and @Data(chainable=true)

M.

[Roel Spilker]

Hi Dan,

That is a great idea. Currently, we have a lot of stuff going on. So
implementing new features is not the highest priority. Things we're
working on, not in any specific order:
- Get type bindings for Eclipse: we really NEED the type bindings in
order to do more cool stuff
- Create De-lombok: for tools like GWT, PMD etc. we need to be able to
actually generate the source code so other tools can use it
- Improve Eclipse refactoring support: now the user can get unexpected
Eclipse error messages during refactoring code that contains lombok
features
- Improved javadoc support: make sure all generated methods show up in
your javadoc
- Enhance existing features
- Investigate NetBeans support

That said, having a prioritized list of requested features is always a
good thing.

Roel

[Roel Spilker]

I'm not sure about the serialVersionId. It becomes part of your
contract. So you either have to manually set it to a value, and then
the regular source code is a good place to put it, or you get a
generated one, and then java will calculate it for you.