On Wed, Apr 04, 2001 at 05:45:27PM -0400, Chuck Esterbrook wrote:
> I have mixed feelings about active attributes. (Hope I don't spawn a big
> discussion here.) I have decided to stick with accessor methods and
> underscored data attributes in Webware.
Well, Chuck is our benevolent dictator so what he says, goes.
However, the reason it became a big discussion is because the issue is a
basic one, and it will come up again and again as users discover Webware
and wonder, "Why does it have these un-Pythonic accessor methods?"
Accessor methods come from C++, Java, Perl and the "never access an
instance's attributes unless you're a subclass" school of OO programming.
Which leads to such monstrosities in Java as:
string3 = string1.concat(string2); # Python: s3 = s1 + s2
string1.lessThan(string2) # Why not "string1 < string2"?
bigint1.add(bigint2) # But "int1 + int2" works fine
vector.subscript(30) # Why not just "vector" ?
hash.setSubscript("A", 5) # Python: "dictionary['A'] = 5"
I don't remember the exact method names but you get the picture. Java
has these wonderful operators (+, ==, ), but you're only allowed to
use them on primitive types. Grrr! One of the reasons I switched to
Python was to get away from that, because *intelligent* operator
overloading really does make the program more readable.
Python is blessed with a very elegant, simple and intuitive set of
module names, method names, and use of pseudo-dictionaries and
pseudo-file objects when appropriate. Having "Field()" and
"setField()" methods is inconsistent with this, which is the reason
for the opposition.
Perhaps it's not something we can address now, but until *something* is
done to placate the "this feels like a dictionary, why isn't it?"
crowd, the issue will keep coming up every few months. Those people
will just write subclasses or add methods to retrofit the dictionary
interface onto their objects, thinking all the while, "Grr, why do I
have to do this?"
> Or if you know that all other classes in Webware used methods for accessing
> named objects (including other kits like MiddleKit and UserKit), then it's
> an extra step to remember that the one exception is Session.
But one can turn this around and say, "Python includes all these
__getitem__ methods, and most other Python modules use them when they
can (or even introduce attribute access when writing a wrapper module
for a foreign library), why the extra step to remember that the one
exception is Webware?"
> > I'd argue the same thing
> >for req.fields['key'], res.cookies['key'], res.headers['key'], etc.
> Meaning that these should also be dict like? Does req['foo'] mean a field
> or a cookie, or both? If both, how is a name conflict resolved? Likewise
> for response...
I think we are mostly talking about dictionary access for unambiguous
items, as in the example quoted. Merged items like plain ol' req
*should* perhaps use a method call to show that they're doing "something
Of course, the Zope way would be to just merge the namespaces in a
predetermined order... (as PHP does if you set the option to register
simple variables for all get/post/cookie items, although programmers are
now encouraged for security to use the separate get/post/cookies
One point worth stressing is that unless the proposed dictionaries offer
both read *and write* access to the object, half the point of adding the
dictionaries would have been lost.
-Mike (Iron) Orr, iron@... (if mail problems: mso@...)
http://mso.oz.net/ English * Esperanto * Russkiy * Deutsch * Espan~ol