Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XOM design

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Edwin Goei <edwingo AT sun.com>
  • To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM design
  • Date: Mon, 02 Dec 2002 18:55:17 -0800

Would it be correct to summarize your view that you do not like method call chaining? Then this would explain your objections. Playing devil's advocate for the moment and assuming one does like method chaining.

Elliotte Rusty Harold wrote:

Setter methods should return void. Partially, this is based on my experience with JavaBeans, where returning void is necessary for a method to be recognized as a property setter.

True, nodes could not act as JavaBeans, but I think this is a good tradeoff because using nodes as JavaBeans may not be a common use case.

However, more importantly, it's semantically the right thing to do. By invoking a setter method (or any adder or mutator method) you are changing an existing object. You are not creating a new object. You are not getting a reference to some value that you did not have before. Nothing has been created that did not exist before. There is no justification for returning anything.

So would it be accurate to summarize your view: mutator methods should not return anything? This just happens to prevent method chaining.


This naturally prevents method chaining, but perhaps this is a good thing. I find long strings of method chains to be ugly and unreadable. For example, consider this JDOM code:

(new Element("word")).appendChild("d").appendChild("o").appendChild("g");

Does this create <word>dog</word> or <word>god</word>? How sure are you of your answer? What if the middle method call throws an exception? What state is the object left in? Again, how sure are you of your answer?

I think users would expect that you would first append "d" which returns the same Element, then append "o", then append "g" to get "dog".

As for exceptions, I think users would expect that if the middle call throws an exception, then the state would be just the same as if the middle appendChild() call throws an exception in the non-chained case. So I don't see how this is much different.


Dividing this statement up into multiple relatively atomic operations makes the code cleaner, easier to read, easier to understand. Yes, there are classes in the Java class library that don't operate this way, most notably StringBuffer. Perhaps this makes sense for StringBuffer, where it's basically the equivalent of the + operator. Honestly though, this is really just a sop thrown to performance to avoid allocating lots of extra strings. Logically, the plus operator should do what it does for numbers: return a new object that is neither of its operands.

Allowing method chaining still allows one to write in a style that does not use it. However, I suppose you probably would say it is a feature to force users into a single non-chained style.


There is simply no logical justification for a setter or mutator method returning the object itself. It is a crutch designed to support a particular programming idiom, but that idiom is neither necessary nor helpful. Method call chaining is not an improvement.

Perhaps your main objection is that you think mutator methods should not return anything and not method chaining per-se. Or is it both?

-Edwin





Archive powered by MHonArc 2.6.24.

Top of Page