We experimented with a short line length in order to facilitate seeing 2 files at once but we didn't find the benefits worth the hassle.
I'll gladly put in the effort to reformat a patch, or look the other way and accept one with a different code style, if its cool enough. On Oct 13, 5:28 pm, B Smith-Mannschott <[email protected]> wrote: > On Wed, Oct 13, 2010 at 16:05, Reinier Zwitserloot <[email protected]> wrote: > > Trivial style whining? For serious? > > Hey, it's your project, so whatever it is, it is. I'll just explain > your conventions to Emacs. It may sulk a little, but I'm sure it'll > get over it. > > > 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 often view two buffers next to each other. This useful when editing > or diffing. As it happens, 80 columns means I can do this even on my > netbook (1024 pixels wide). To do so at 132 columns would require > roughly 1600 pixles horizontally, and most of that space would be > empty because line length is highly variable. So, I'm not really sure > who's handicapping themselves here. *shrug*. > > > 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 > > Yea, I saw the: > > if (...) for (...) { > blah > } > > stuff. Unusual, but reads pretty well. It made me think of Wirth > condensed style. ;-) Except, no, WCS is in a universe of its own: > > procedure GetFileName(uno: integer; var name: array of char); > var i: integer; ch: char; > begin i := 0; > loop ch := UT[uno].name[i]; > if ch = 0X then exit end; > name[i] := ch; inc(i) > end; > ... > end GetFileName; > > but, that's neither here nor there. > > using an auto-formatter is a non-solution as it would make submitting > patches impossible. But then, using hard tabs kind of kills that > anyway, at least via e-mail. Good thing we have github. > > > 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 makes sense. I saw lombok.ast, but wasn't clear how it fit > together with the rest. Sounds like the Right Thing. I'll have a look. > > > 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). > > Ah, I hadn't noticed the once-per-platform bit. I guess I haven't dug > deep enough. > > > > > > > > > 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 > > athttp://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.
