[XML-SIG] Ugh! Why are DOM access methods spelled with a leading '_'?

Jim Fulton jim@digicool.com
Mon, 26 Jun 2000 16:03:44 -0400


Mike Olson wrote:
> 
> Jim Fulton wrote:
> >
> > Mike Olson wrote:
> > >
> > > Jim Fulton wrote:
> > > >
> > > > >
> 
> > >
> > > In 4DOM, we are actually moving away from __getattr__ (for speed).
> >
> > IMO, this is strong evidence that the Python DOM should
> > *not* use attributes for implementing the DOM/IDL attributes.
> 
> Huh?  I see exactly the opposit picture.  Functions were only needed
> until all of the issues with current state could be worked out.

What current state?

> Most of
> them arose in DOM L1, but have been clarified in DL2.  Dom L3???? If we
> don't need the over head of __getattr__ override then why should we have
> it?

DOM defines many useful attributes like parentNode and 
previousSibling.  If these are exposed as attributes in the Python
DOM mapping then either:

  - Implementors of the DOM must *store* these attributes or

  - implement getattr to provide access to the attributes via
    computation.

I don't want to restrict DOM implementations to store these attributes
and I don't want to burden DOM implementations with the hassle or
overhead of implementing getattr.

> Are you proposing all access through functions?

Yes.
 
> > I'd like it to be as easy as possible for various objects to implement
> > the DOM. (See for example StructuredTextNG.) I'd hate to make implementers
> > go through the pain and performance hit of getattr or dictate an implementation
> > (like caching attributes or otherwise directly storing them, creating
> > memory leaks).
> 
> To me, difficulty is more defined by the API then how we map it.  We
> don't add any complexity to implementing the DOM interface to say that
> finctions should start with a '_' or end with a '_'.  Its just a naming
> convention. 

We weem to be arguing two issues:

  - Whether to expose DOM attributes as Python attributes or
    accessor functions, and

  - How to spell the accessor functions.

If we go with accessor functions, which I think would be 
a good idea, then the accessor functions should be
names in a way that is consistent with Python practice.

(Those of you who are familiar with Zope may appreciate
 that I have an extra reason to avoid '_'s because Zope
 incorporates the use of leading '_'s to indicate private
 attributes into it's security policies.  Accessor functions 
 with names beginning with '_'s are currently inaccessible to 
 through-the web code and RPC.)

> Most of the difficulties in implementing the DOM are
> impementaiton specific.  For an in memory version in python, you don't
> need computed atributes. 

You do if you want to avoid circular references.

> If you want to write a pulldom, you probably
> will. 

I have no idea what this is. I don;t think I need to, :)

> If you are writing DOM in zope you will.  DOM in C++ maybe.
> 
> I think it should be left up to the implementator as to whether they
> need computed attributes.

We could and should avoid the issue altogether by using access methods.
If someone wants to store the attributes, then the access methods
can simply return them. If computation is needed, then that's easy
enough.

By using attribute syntax, then you force people to deal with 
getattr unless they want circular references, at least for
attributes that deal with parents, siblings and such.

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.