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