[XML-SIG] 4DOM future

[Ken MacLeod]

uche.ogbuji@fourthought.com writes:

> Hmm.  I'm a bit unclear as to which way you're leaning:
> node.get_parent() or node.parent?  I see clearly that you think
> either is preferable to mixed-case (getParent()), and I agree with
> you in this particular domain,

I prefer node.parent.

> but I'm also interested in your (and others') opinions as to
> 
> * Whether the greater pythonic feel of get_parent() or parent is
> worth the disruption to current users of 4DOM.

I think the most important point is that all the Python DOM
implementations share the same binding spec, so the important issue is
the disruption of current users of any DOM impl. to the agreed upon
spec.  For that, I'm in the ``do it right, and the sooner the better''
camp.  Then, after that, I prefer node.parent over node.get_parent().

> * Whether get_parent or parent is superior: there is the Pydom
> precedent for get_parent() and the ECMAScript precedence for parent.

FWIW, I don't like get/set routines when a language offers better
solutions.

> * Whether the __getattr__ & __setattr__ overhead of parent would be
> worth it for a pure attribute idiom that after all seems to be the
> intent of the DOM rec.

I don't process megabytes of XML in short spans of time, any overhead
would be minimal for me.  Others do process megabytes of XML in short
spans of time, you should test an implementation both ways since a lot
of performance issues are already inherent in DOM.  If I were
designing a system to do large XML instances, I would probably still
accept 10-15% (though I'd suspect it would be even less than that).

Between node.parent and node.get_parent() would be node.parent() for
get and node.parent(value) for set.


I should note that I'm probably not a representative user, I'm not a
heavy DOM user.  I generally prefer to convert in to and out of
application objects using SAX.  My application objects almost always
use the node.parent style of attribute access.

-- 
  Ken MacLeod
  ken@bitsko.slc.ut.us