Re: [dom4j-dev] Why do add(...) methods return void?

[James Strachan]

Would people prefer addAttribute? +1 In the dom4j model, since you can have an attributeIterator, I see the attributes as "widgets" belonging to the Element, rather than as properties. The "only one value" constraint could be handled with an IllegalAddException, or (preferred) the existing logic of changing the value. "addAttribute (name, value)" only looks peculiar where you _know_ the attribute exists, and want to change its value: in which case you'd probably have a reference to the Attribute anyway, and would update it with attribute.setValue(). +1 as well from me. It would make things more consistent. Now I come to think of it setAttributeValue() is a bit of a mouthful.     I keep reminding myself that I reckoned 18 months - 2 years experience was required before I could turn a junior C programmer loose on core C++ modules - IMHO, one of Java's greatest strengths is that this has come right down.   Agreed. The fact that Java is easy to read and there are fewer gotchas makes life much easier and makes us all more productive. I've never quite got into XMLC. I wonder if we need a dom4j equivalent? <off-topic> YES YES YES! The major pain with XMLC is working with DOM. But AFAICT in order to use the accessors / mutator methods generated by XMLC you'd need a version of XMLC which built a dom4j Document subclass instead of a w3c.dom.Document subclass? At present, I can either wrap the XMLC object in a dom4j wrapper and dispense with the get...() and set...() methods, or hack around in DOM. XMLC gives a very clean separation of responsibilities between us cave-dwellers and the graphics bods; a dom4j implementation would be genuinely useful. No time to work on it right now, maybe in a few weeks time? Ideas?     Actually I think the thing that put me off XMLC was the fact that it was based on DOM so I never looked too deeply.   Maybe if we used the same idea, code generating dom4j code from a source document allowing an easy way to customise & add dynamic behaviour, it might be easier to use. Especially with Java 2 Collections, XPath and XSLT support built in.   I'll add that one to the to do list...   James