3 ms·

I don't think it's a bad question, and it's not like there's a right or wrong answer to any of it. To me, the reason why in the example I gave a builder is bett

I don't think it's a bad question, and it's not like there's a right or wrong answer to any of it. To me, the reason why in the example I gave a builder is better than a config object is because objects necessitate all their fields to be set upfront. You could then say, "Well why don't you just have getters and setters for all of those fields?". And it's like, ok sure, we could do that, but what if something else is using that object and we're mutating it? So then you could say, "well what if the setters return a *copy* of the object, the you can then pass along?" And then it's like, ok, well now we basically have a builder, we're just calling it different things.

kragen 5y ago
> what if something else is using that object and we're mutating it? You're probably aware that in Rust we have other, better safeguards against that, and you were probably talking about languages like Java and C++ where you don't, but I thought I'd mention it in case someone reading the thread doesn't know that.
- asimpletune 5y ago
  Yeah totally, I just meant as a pattern. Nonetheless, in rust even though you may have the borrow checker to safeguard against the mistake, that still leaves you with now needing to accomplish the thing, in spite of the borrow checker. Which is where using a builder would be one way to do it. So even rust you still need *something*, it’s just safer and more obvious to see why, because you literally can’t share the reference in two places.