Re: Builder class naming consistency

Quick followup as I chug through the archives: I've been using setFoo() since it's easier to generate. Just create setters, then copy/paste the return type from void to Builder and add a "return this;" line to each method. It's rather manual, but the IDE plugins I've tried using to do this in the p

Re: Builder class naming consistency

Oh, right. I forgot the setter was on the builder, not the actual object. Forget I said anything. Ralph > On Nov 30, 2015, at 3:11 PM, Matt Sicker wrote: > > Builders are for creating immutable objects. > > On 30 November 2015 at 15:30, Ralph Goers > wrote:

Re: Builder class naming consistency

Builders are for creating immutable objects. On 30 November 2015 at 15:30, Ralph Goers wrote: > Generally I prefer factories over builders because the objects created are > immutable. OTOH, the new Builder for the Configuration creates an > intermediate object. The actual objects use the “normal

Re: Builder class naming consistency

Generally I prefer factories over builders because the objects created are immutable. OTOH, the new Builder for the Configuration creates an intermediate object. The actual objects use the “normal” plugin builders/factories so they can still be immutable. Ralph > On Nov 30, 2015, at 12:49 PM,

Re: Builder class naming consistency

Right, to me using "with" implies getting a *new* object/copy. Gary On Mon, Nov 30, 2015 at 12:17 PM, Paul Benedict wrote: > Gary, I also prefer "set" but I didn't want to pollute my objectivity in > explaining the options. My cards are now laid down. :-) BTW, "with" has > been used in JSR-310

Re: Builder class naming consistency

Gary, I also prefer "set" but I didn't want to pollute my objectivity in explaining the options. My cards are now laid down. :-) BTW, "with" has been used in JSR-310 (Java 8 Date/Time) for immutable objects "mutability"; that prefix means you get back a new object when "changing" the property (thin

Re: Builder class naming consistency

I find using foo() instead of setFoo() somewhat confusing. It forces you to think that you are using a builder and you cannot just do set/auto-complete. In addition, when foo is a verb, it's misleading, since the call does not perform anything but merely sets a value. Gary On Mon, Nov 30, 2015 at

Re: Builder class naming consistency

I actually had an interesting discussion lately with builders; so this topic interests me. Since builders are inherently mutable (and they should be right? it's a process of constructing an object), it's okay to use "set" methods. For example, see Spring's BeanDefinitionBuilder [1]. But you don't h

Re: Builder class naming consistency

I like "set" better, but that's just because I like to type "set" and use auto-complete. I'd rather not have to decide if I have to type "set" or "with" and then auto-complete. Gary On Mon, Nov 30, 2015 at 11:36 AM, Matt Sicker wrote: > Sorry, but I introduced this problem a while ago by using

Builder class naming consistency

Sorry, but I introduced this problem a while ago by using withFoo() in some builder classes, but setFoo() in other builder classes. Both are equally valid naming schemes for builder classes. It would be great to be consistent, though. Which one would be preferable? -- Matt Sicker