3 ms·

Yes. In such a case you would need to clone the object. Having toUpper() clone by default is wasteful if you don't need a clone. Hence using "return this".

• AndrewDucker 15y ago
  And I would argue that the reason that C# and Java have both gone for making strings immutable is that it is less confusing. I value code that's less confusing over code that allocates extra objects (largely because the last time I wrote some simple benchmarking code I could allocate multiple millions of an object in a second).
  • mullr 15y ago
    I'm not sure if it's really less confusing. I once spent about an hour struggling with string.Replace in C# before I bothered to read the documentation. Falls into the 'gotcha' bucket in my mind. Now, I'm pretty sure that strings are interned in C#, so making them immutable makes a lot of sense from that perspective. It's just that the language encourages mutable state in so many other areas that it's a bit of a mental shift when you have to deal with strings. In Java... afaik strings aren't interned by default, so I can't really argue for immutability there. The original author's argument for method chaining feels like a separate case altogether. Really it's primarily used when building embedded DSLs in these languages. In that case, standard semantics be damned; do what you need to to make the code look how you want.