I actually wrote this about a month ago, but for various reasons it hasn't emerged 'til now... so if it seems hokey and out of date, I blame the posting delay rather than my intrinsic lack of insightfulness :)
Nathan recently blogged about
Python's neat approach to getter and setter methods, namely the
This allows programmers to
seamlessly "upgrade" from naive direct access to class members e.g.
foo.x to contract-maintaining getter and setter
functions without changing the interface, by declaring
def getX(self): ... def setX(self, newx): ... x = property('x', get=getX, set=setX)
or, the even neater new read-only property decorator form
@property def x(self): ...
and its optional setter extension:
@x.setter def x(self, newx): ...
This is very sweet and I'm ashamed to say that despite writing more Python than Nathan I wasn't aware of it. (This lack
of advertisement is neither new nor unique to properties --- Python's "special" method names aren't exactly promoted in
the official docs, either.) As well as (as Nathan points out) breaking the tedious routine of getter/setter boilerplate
code ("just in case it becomes huge and complex later..."), first class properties also have a nice aesthetic
consequence which is that there is only one standard way to access data members. While I would squirm a bit at seeing
foo.getx() rather than
foo.getX(), I have no problem at all with
foo.x. Obviously this is stupidity on my part,
but not having the room to build opposing schools of coding convention is in its way rather liberating. We're so
accustomed to seeing property access denoted by parentheses, that I find this notation rather refreshing: if used to be
that you had to go to rather obscure, usually functional, languages to get such a change of syntactic scenery, so it's
nice to see the architects of a major and popular language thinking beyond the more redundant wrinkles of C-centric
On the other hand, while this is undoubtedly cool, I do still have The Fear when it comes to deploying Python on big projects. The lack of any significant pre-run type-checking still scares me and I sometimes get the feeling that weakly typed languages are a fast-track route to unmaintainable code unless some serious development discipline is wielded. On the other hand, the biggest bits of Python code I've written are more maintainable than they have any right to be! Ideally, Python would have some sort of "static duck-type checking", i.e. attempting to verify that the required object methods should normally be present. That's impossible generally, perhaps to the extent that it's a completely dumb idea, but with C++ I find that ditching polymorphic typing via inheritance hierarchies in favour of template-based duck typing can be very handy. Of course, the downside is that the rest of C++ is evil. (Largely due to its unholy trinity of raw pointers, manual memory management and the legacy can of worms that is the C preprocessor. A recent long discussion with an experienced C++er has only reinforced my opinion that most clever C++ tricks and idioms exist to fix problems introduced by one of these three. And the innocuous looking preprocessor is responsible for a good half of those. Work I've done since then on heavily templatey (i.e. header-obsessive) C++ code has reinforced it even more.)
Java is much better --- not only does it have a garbage collector and a compilation model without medieval overtones, but since version 1.5 we also benefit from a more powerful and subtle generics system than C++, built-in reflection and the killer metadata feature: annotations. Even more cool is the porential of the combination of Java with Jython: the Jython interpreter speaks and writes Java bytecode, meaning that true interchangeability of code objects is possible. Not only possible, but easy: Jython can run Java library classes out of the box without the need for wrapper systems like SWIG and Boost.Python. I think this really is the way of the future: a common bytecode on top of a lightweight VM allows programmers to choose appropriate languages for different tasks without either reinventing wheels or breaking a sweat. This isn't just faciful extrapolation, either: the JVM apparently now plays host to over 200 languages including Scala, a neat functional OO language, Jython, BeanScript, PNuts and Groovy. Maybe the time of the virtual machine has come after all.