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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
