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

Jim Fulton jim@digicool.com
Tue, 27 Jun 2000 11:33:06 -0400


Paul Prescod wrote:
> 
> tpassin@home.com wrote:
> >
> > Jim Fulton continued the attributes thread -
> >
> > I still don't see why anyone is still arguing about whether the DOM rec
> > makes Python use attributes.  It doesn't.
> 
> Nobody is arguing that. Some people *were* arguing that the DOM rec
> mandates the use of methods (or, more precisely, that DOM ID + Python
> IDL mapping = methods). But the DOM IDL is clearly not normative because
> it doesn't even parse as IDL. So we can put that argument to bed. We
> need to make the decision on technical and aesthetic merits.

Thanks for laying the issue out in a nice table. Sorry for messing it
up.

Some people have argued that a decision was already made some time ago, 
and that we shouldn't have to cover old ground.
(Somebody eaven sent me a pointer to the discussions, which I've 
missplaced. :() If a decision *really* was made, then I'm willing
to abide by the decision. I have no idea how SIG decisions are made
unless Guido gets involved ..... In any case, a decision needs to
be published and actually known to have any value.
 
> Attributes:
>         * arguably more Pythonic (=easier to use)

I think that this extremely arguable.  Many people would argue 
that it's less OO and, therefore less Pythonic. I obviously
(from other work) think computed attributes are OK, however, I
think they have significant downsides, especially for an API
that we might want people to implement.

          + easier to use

This should be added as a separate bullet.

>         * faster for non-computed attributes
>         * slower for computed attributes
>         * more like Javascript, VB and COM-like languages (C# :) )

Who cares?

          + much harder to implement for computed attribues
 
> Methods:
>         * slower for non-computed attributes
>         * faster for computed attributes
>         * harder to implement

Do you really mean this? What's so hard about:

  def getFoo(self): return self.foo

???

>         * more like Java

Who cares unless it is *less* like Python, which it isn't, IMO.

Here is an additional, admitadly Zope-specific argument for accessor
methods:

          + Easier to assign access meta-data, such as security assertions.

In Zope, we can assign attributes to methods, which allows us more
control over access. Accessor functions are much more friendly to
the Zope security machinery. Obviously, the API should not be
giverned soley by Zope's needs.

 
> There are no killer arguments here, just different weights applied to
> the various features. I don't think that we are going to agree to break
> code today. Maybe later we'll see that there are more DOM implementors
> than clients and their ease of implementation will take precedence.

Do you really think that "x.getY()" is significantly harder to use
than "x.y"?

I can definately tell you that computed attributes are very significantly
much harder to implement than accessor functions.

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.