[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Greenspun's tenth law rears its head: was InnerXml is like

• To: "'Elliotte Rusty Harold'" <elharo@m...>, <xml-dev@l...>
• Subject: RE: Greenspun's tenth law rears its head: was InnerXml is like printf (WAS: Underwhelmed)
• From: Bill de hÓra <bill.dehora@p...>
• Date: Mon, 23 Sep 2002 16:44:24 +0100
• Importance: Normal
• In-reply-to: <p04330101b9b4d0f7b89a@[192.168.254.4]>
• Organization: Propylon
• Reply-to: <bill.dehora@p...>

> From: Elliotte Rusty Harold [mailto:elharo@m...] 
>
> Hmm, I'm willing to consider whether append() alone might be 
> sufficient instead of "appendChild" but I think "append" is 
> demonstrably better than "add".

Yes it is. The answer to your consideration is in the question: can I
add anything other than a child node?

 
> Your suggestion is pretty good, but I'm hesitant to rely on 
> indentation to convey meaning. 

Granted. If you go wild with nested append calls combined with embedded
constructors, you will depend on whitespace. You always depend on
whitespace, but especially so there; much the same way as you would to
make anonymous inner classes readable. Chaining append() calls doesn't
impose the same level of care:

 Element a = ...;
 Element b = ...;
 Element c = ...;
 Element d = ...;
 Element e = ...;
 d.append(a).append(b.append(c.append(e)));

is not imo unreadable, more importantly it can be made idiomatic:

 Element a = ...;
 Element b = ...;
 Element c = ...;
 Element d = ...;
 Element e = ...;
 c.append(e);
 b.append(c);
 d.append(a).append(b);

I wouldn't consider making a developer choose between either of those
and this:

 Element a = ...;
 Element b = ...;
 Element c = ...;
 Element d = ...;
 Element e = ...;
 c.append(e);
 b.append(c);
 d.append(a);
 d.append(b);

to be a feature in an API. Each to there own comprehension. My
experience is that I'll move the code around to suit depending on what
I'm doing.


> Also keep in mind, that 
> one of my design principles is that XOM by its nature should help 
> inexperienced developers do the right thing and keep them from doing 
> the wrong thing. 

Yes. On the other hand, experienced developers may grow tired of an API
that does too much handholding or is verbose through use. My inclination
would be to target capable Java/XML developers and lift the rest up by
other means ("Effective XOM")


> The learning curve needs to be really shallow, and 
> that includes not relying on best practices that are known in the 
> community but are not obvious at first glance.

I think the problem you'll have is leveraging Java developers away from
JDOM and DOM. JDOM is going through the JCP and the DOM ships with the
JDK. So long as the API isn't littered with calls, it'll be easy enough
to grasp (my favourite Java API is Javaspaces, which is effectively one
class).

Bill de hÓra 
--
Propylon
www.propylon.com 

 

• References:
  • Re: Greenspun's tenth law rears its head: was InnerXmlis like printf (WAS: Underwhelmed)
    • From: Elliotte Rusty Harold <elharo@m...>

• Prev by Date: RE: Greenspun's tenth law rears its head: was InnerXmlis like printf (WAS: Underwhelmed)
• Next by Date: RE: InnerXml is like printf (WAS: Underwhelmed)
• Previous by thread: Re: Greenspun's tenth law rears its head: was InnerXmlis like printf (WAS: Underwhelmed)
• Next by thread: "The serialization of the XML Infoset is XML" (WAS: Underwhelmed (WAS: XOM micro tutorial))
• Index(es):
  • Date
  • Thread