4 ms·

Return "this" in java instead of cloning objects.

4 points by hmottestad 15y ago

slifty 15y ago
Taking a lesson from jQuery I see.
- TNO 15y ago
  Fluent interfaces predate jQuery
AndrewDucker 15y ago
Only useful if you do not mind your objects being mutable. otherwise: string name1 = "Andrew Ducker"; string name2 = name1; name1.toUpper(); means that name2 is now also "ANDREW DUCKER" when we quite possibly didn't want it to be.
- hmottestad 15y ago
  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.
sausagefeet 15y ago
I totally thought this post was going to be about methods just recording what the user wanted to do in a list and then have an apply method at the end. I'm not sure why I thought that...
asymptotic 15y ago
The idea of chained calls all returning this forms the basis of the phenomenally useful Builder Pattern, from Bloch's "Effective Java". There are three main reasons for using the Builder Pattern: 1) Allows for "constructor-like" calls to functions that don't necessarily share the name of the class. 2) Allows for complex, multi-parameter "constructor-like" calls without needing to make one massive function call. 3) Allows intermediate argument checking on particular constructor arguments, and allows sane optional constructor arguments. (I find this pattern very useful). See: http://rwhansen.blogspot.com/2007/07/theres-builder-pattern-that-joshua.html http://rwhansen.blogspot.com/2007/07/theres-builder-pattern-... http://stackoverflow.com/questions/5007355/builder-pattern-in-effective-java http://stackoverflow.com/questions/5007355/builder-pattern-i... https://manuelselva.wordpress.com/2010/04/09/effective-java-2nd-edition-builder-pattern-in-eclipse/ https://manuelselva.wordpress.com/2010/04/09/effective-java-...

4 points by hmottestad 15y ago

slifty 15y ago

Taking a lesson from jQuery I see.

TNO 15y ago
Fluent interfaces predate jQuery

AndrewDucker 15y ago

Only useful if you do not mind your objects being mutable. otherwise: string name1 = "Andrew Ducker"; string name2 = name1; name1.toUpper(); means that name2 is now also "ANDREW DUCKER" when we quite possibly didn't want it to be.

hmottestad 15y ago
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.

sausagefeet 15y ago

I totally thought this post was going to be about methods just recording what the user wanted to do in a list and then have an apply method at the end. I'm not sure why I thought that...

asymptotic 15y ago

The idea of chained calls all returning this forms the basis of the phenomenally useful Builder Pattern, from Bloch's "Effective Java". There are three main reasons for using the Builder Pattern: 1) Allows for "constructor-like" calls to functions that don't necessarily share the name of the class. 2) Allows for complex, multi-parameter "constructor-like" calls without needing to make one massive function call. 3) Allows intermediate argument checking on particular constructor arguments, and allows sane optional constructor arguments. (I find this pattern very useful). See: http://rwhansen.blogspot.com/2007/07/theres-builder-pattern-that-joshua.html http://rwhansen.blogspot.com/2007/07/theres-builder-pattern-... http://stackoverflow.com/questions/5007355/builder-pattern-in-effective-java http://stackoverflow.com/questions/5007355/builder-pattern-i... https://manuelselva.wordpress.com/2010/04/09/effective-java-2nd-edition-builder-pattern-in-eclipse/ https://manuelselva.wordpress.com/2010/04/09/effective-java-...