[XML-SIG] The '_' thingy

[Jim Fulton]

Mike Olson wrote:
> 
> Jim Fulton wrote:
> >
> > Mike Olson wrote:
> > >
> > > So, I think I see this as a general concensius:
> >
> > Are you kidding?
> 
> No.  '_' issues aside I think most people want attribute access.  I
> didn't tally a vote or anything, but that was the sense I got.  Am I
> wrong?

I certainly don't think that there is concensus.

Unfortunately, I have no idea if there is a process for making
these decisions in a SIG where there is disagreement. Unless, of
course, the Benevolent Dictator decides to get involved. ;)

> >
> > > 1.  DOM will never (in forseeable future) be used over an ORB, so the
> > > IDL should be used as a guide.
> >
> > Uh, this doesn't make sense.
> 
> We don't need to stick strickly to IDL (I don't think that was the
> original intention), because we won't be doing distributed DOM for a
> while.

Then perhaps you meant to say that "IDL shouldn't be uses as a guide".

I think we agree not to base the Python DOM API on the
Python IDL mapping.
 
> > >
> > > 2.  Most people will access the DOM via attributes.
> >
> > Who says? What do you have to support this? Most people
> > will access the DOM through whatever interface we define.
> 
> Again, just the sense I got.
> 
> So where are we at on the attribute vs. accessor debate?

I dunno.
 
> I throw in my hat for attribute

I disagree. :)
 
> >
> >
> >
> > Whatever path we start down, it should begin with a draft
> > that documements the DOM mapping for Python.
> 
> Agreed, but I think we can work out some of the larger issues on the
> list.
> 
> >
> > > A
> > > langauge mapping is something we can put into the next release of 4DOM
> > > (something we've been meaning to do any ways).  The rest of the cahnges
> > > are actually in place (unless we define a different callback naming
> > > convention).  We will be slowly depricating _get_* soon as well.
> > > However we will still need __setattr__ callbacks in some cases....
> >
> 
> >
> > In summary, I think using attribute-based access for the Python DOM
> > API would be a mistake because it will make efficient DOM implementations
> > harder than necessary to create. I'd prefer to see accessor functions used
> > to provide access to DOM attributes.
> >
> > There has, however, been relatively lettle discussion on this.
> > I'm curious what opinions others have.
> 
> Jim, I don't see your arguements.
> 
> How is n.firstChild less efficent the n.get_firstChild() ?

It's not if you constrain the implementation to store the first 
child. If an implemantaion chooses not to store the first 
child indepenent of the chidren, then the implementatin must
implement __getattr__.  It's worse for (the few) settable attributes, 
because the implementation *must* implement the attributes as stored 
attributes or implement __setattr__.

> In the first, you modfy appendChild, et al and at the end put in if
> self.childNodes[0] == newNode: self.firstChild = newNode
> 
> In the second you do a "return self.childNodes[0]"
> 
> I don't see a major memory or speed difference?  You can do the same for
> all other attributes.

Oh? What about parentNode and previousSibling?  If you store these
directly, then you introduce a circular reference. 
 
> I don't see how accessors call get around circular references either.
> Believe me we have tried with this one.  We have come up with a few
> schemes in our time, proxied nodes and such, but nothing that made it
> worth the overhead.  Its much simplier/efficient to have a utility
> function to clean up a tree if you need it too.

You may think that this is the right design tradeoff, but I don't agree with 
you.  You can get around the circular references with Acquisition and
with a similar wrapper-based technique. My DOM implementation for 
StructuredTextNG uses a wrapper-based approach that avoids circular
references without using Acquisition.

It is straightforward to implement accessor functions regardless of
the underlying design, while implementation of attribute access is
complicated and inefficient when designs that avoid circular references
are used.

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.