XOM API for Processing XML with Java

[Edwin Goei <edwingo AT sun.com>]

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