Depends on what you mean here...
a mutable builder that creates an immutable object:
ObjBuilder builder = new ObjBuilder()
builder.setX(1)
builder.setY(2)
builder.setZ(3)
Obj obj = builder.build()
an immutable object with a set of withXXX() methods that return a copy of
the object with that value updated
Obj obj = new Obj()
.withX(1)
.withY(2)
.withZ(3)
a succession of immutable objects, each bulding on the previous with an
additional value
class ObjBuilder {
ObjBuilderWithX withX(int x) { return new ObjBuilderWithX(x); }
}
class ObjBuilderWithX {
public final int x;
public this(int x) { this.x = x; }
ObjBuilderWithY withY(int y) { return new ObjBuilderWithY(x, y); }
}
class ObjBuilderWithY {
public final int x;
public final int y;
public this(int x, int y) { this.x = x; this.y = y; }
Obj withZ(int z) { return new Obj(x, y, z); }
}
class Obj {
public final int x;
public final int y;
public final int z;
public this(int x, int y, int z) { this.x = x; this.y = y; this.z = z; }
}
On 13 October 2010 15:33, Erlend Hamnaberg <[email protected]> wrote:
> Interesting.
>
> Would it be possible to make immutable builders as well?
> I've had quite a few uses for them.
>
> --
>
> Erlend
>
>
> On Wed, Oct 13, 2010 at 4:05 PM, Reinier Zwitserloot
> <[email protected]>wrote:
>
>> Trivial style whining? For serious?
>>
>> I'm sure your editor has an auto-format feature of some sort. The tab
>> style is OTTS, which means that, whatever tabstop you've configured
>> your editor on, the indents never look weird. I've got a massive
>> screen at home, as do the other core lombok contributors. Why handicap
>> ourselves? I would have expected you to fall over our liberal use of
>> one-line if and for statements, which an auto-formatter can't fix :P
>>
>> The booleans are a hold-over from an old mechanism which is now
>> virtually never used. We're rewriting this part of the API. We've
>> written our own much nicer API for manipulating an AST (it's on
>> github, at lombok.ast), and we're integrating this into lombok proper.
>> That way you only need to write a transformer once, instead of the
>> current status quo (once PER platform. Currently there are 2
>> platforms, javac/netbeans and ecj/eclipse, though we want to add
>> IntelliJ's parser to this eventually), and the API is documented (and
>> much, _much_ nicer).
>>
>> FWIW, our plan for builders is to offer some sort of @Builder
>> annotation which creates the works: A builder class, builder() and
>> make() methods, field-named methods (just firstName(...), not
>> setFirstName), which return the builder, and all that. When going
>> through all that effort there's not much point in our opinion of
>> keeping the class itself filled with setters, i.e: It makes more sense
>> to make the class itself immutable.
>>
>> On Oct 13, 8:21 am, B Smith-Mannschott <[email protected]> wrote:
>> > On Tue, Oct 12, 2010 at 23:59, Reinier Zwitserloot <[email protected]>
>> wrote:
>> > > Rolling your own lombok plugin to produce builder pattern style stuff
>> > > is trivial.
>> >
>> > 132 columns and hard tabs? for serious?
>> >
>> > Well I dove in at HandleData and am now scratching around in
>> > HandleGetter. It's about as I expected, considering that it's
>> > manipulating a JavaC's private AST in Java.
>> >
>> > The obsession with returning booleans for everywhere confused me at
>> > first. For example, createGetterForField returns boolean, but in fact,
>> > in only ever returns true, which is good, since createGetterForFields
>> > completely ignores all the booleans returned by createGetterForField
>> > and just returns its own 'true', hard coded. Who needs that?
>> >
>> > Really, it's just about the public handle(...) method returning a
>> > boolean (a success value of some kind, I imagine), and your probably
>> > just trying to be consistent [1], since generateGetterForType actually
>> > can return false.
>> >
>> > [1]
>> http://quotesnack.com/ralph-waldo-emerson/a-foolish-consistency-is-th...
>> > ;-)
>> >
>> > In the meantime, I've managed to convince myself that I understand how
>> > createGetter() works, so, yea, it probably wouldn't be very difficult
>> > to implement my withX(x) builders for immutable types. Supporting a
>> > variant of @Data and @Setter to provide the OP's chainable setX
>> > methods would probably be even simpler.
>> >
>> > Yea, Lombok's a nice bit of work.
>> >
>> > // Ben
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "The Java Posse" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<javaposse%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/javaposse?hl=en.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
--
Kevin Wright
mail / gtalk / msn : [email protected]
pulse / skype: kev.lee.wright
twitter: @thecoda
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
