The power of naming
Posted by aogTuesday, 21 July 2009 at 10:57 TrackBack Ping URL

One of the perenial issues in modern computer science is the naming of what are called “accessor” methods. You have a class and it has some POD1 members. Because we are all so functional and encapsulated these days, you are never so gauche as to let other bits of code (“clients”) touch the data directly. Instead clients must call methods on the class in order to access (hence, “accessor”) the data2.

The big issue is, then, what names do you use for those accessor methods? There are two primary schools.

One is the “long name” school, where you have different names for reading and writing. E.g. get_option to retrieve the current value and set_value to write a new value.

The other school is the “overload” school where you use the same name (e.g. option) but distinguish the methods by the number of arguments. That is, you pass nothing to the read method and the new value to the write method.

I personally have, in the past, favored the “overload” style because I find it more succinct and elegant, but have been gradually drifting toward the “long name” style for C++ because of the rise of a more functional (that is, Lispy) style3. The problem with the overload style is passing off references to the method. In the overload style you have to do a clunky static_cast to get the right one, but if you use long names it just works.

No real point here, I just thought you all had been exposed to enough geek speak here lately.


1 Yes, this is an Official Term that is used in technical papers. It was invented to distinguish between data objects that are just pure, passive data and data objects that have functionality attached. Modern compilers are clever enough that they can do a lot of optimizations with POD that is not valid with non-POD.

2 Yes, it’s a bother, but it does pay off in the long run for large software projects and these days, just about everything ends up as a large software project. I would explain how it pays off but I don’t want to get sued by your survivors when it glazes your eyes over permanently. Honestly, most people in the industry don’t really understand why, they just do it because it’s the fashion.

3 C++ is getting real closurescheck it out. Woot! That’s the kind of thing that gets my blood moving.

Comments — Formatting by Textile
Jack Diederich Tuesday, 21 July 2009 at 13:04

Once upon a time I was a C++ guy, so you have my sympathies. Of course if you were using a slightly higher level language then getters and setters just go away. Here is a python class that has a straight Piece-Of-Data member followed by a class that has accessors added. The ‘self’ is an explicit reference to the instance.

class Person:
 age = None

class Person:
  _age = None
  def get_age(self):
    return self._age
  def set_age(self, new_age):
    self._age = new_age
  age = property(get_age, set_age)

To set/get the age for instances of either you just do ‘bob.age > 10’ or ‘bob.age = 65’ In the second case the access goes through the get/set methods instead of manipulating the POD directly. This is handy because you can add the methods later if and when you need them (and you almost never do) without refactoring tons of code.

Annoying Old Guy Tuesday, 21 July 2009 at 13:39

The accessors don’t go away, they’re just hidden under some syntatic sugar. That’s an excellent example of something being transparent in the computer science sense.

SWIPIAW has been learning Python recently. I prefer Perl myself, although I have been coming to like Javascript (there’s a horrible, inappropriate name for you! Of course, the geeks are trying to replace it with “ECMA Script” which is not obviously better). Still, I like C++ and the new standard looks like it’s going to clean up a lot of the accumulated cruft that plagues the language. auto is going to rock.

Jack Diederich Tuesday, 21 July 2009 at 14:26

(thanks for formatting my code snippet)

I came to Python via Perl (longer version of that story). The next rev of ECMA script has borrowed some features from Python (many of which Python borrowed from elsewhere). As for C++, while the new features do look very nice I’ll never use them. These days I only write vanilla C and even then only when I want to speed up a Python inner loop; I drop down to C for 20 lines and then go back to Python.

Python’s property() has the same transparency tradeoffs as C++ or Java style getters/setters. If you see a setter/getter you don’t know if it is just manipulating Plain-Old-Data or doing a complex calculation. Python’s properties are the same but instead of everything looking like a function call everything looks like a straight POD access. The Java style has the extra overhead of requiring you to write the boilerplate get/set funcs up front (or God forbid let your IDE write the code for you).

The convention in Python is to use properties for O(1) operations and explicit get/set functions for everything else as a sigil that says “this might be expensive.” It doesn’t win any points there because you can have conventions in Java/C++ too, name the getter calculateFoo() instead of getFoo().

Annoying Old Guy Tuesday, 21 July 2009 at 14:38

many of which Python borrowed from elsewhere

I call that “Lisp’s Revenge”. If you track those things down, you’ll find that most are re-incarnated features of Lisp. It’s kind of like the Latin of programming languages. It’s poignant for me because I was dragged kicking and screaming in to coding in Lisp and now it’s an experience that is a great comfort to me in my dotage.

joe shropshire Tuesday, 21 July 2009 at 23:16

Speaking of which: what do you think of Arc?

Annoying Old Guy Tuesday, 21 July 2009 at 23:31

I am not familiar with that.

joe shropshire Tuesday, 21 July 2009 at 23:41

Paul Graham’s new dialect, here.

Annoying Old Guy Thursday, 23 July 2009 at 10:29

Looks interesting, although I think he’s rather overly dismissive of object oriented programming. I understand because there are those who promote OOP as The Way but despite that it’s far more useful than Graham describes. I think he missed a lot by not using the Common Lisp Object System which is a very interesting bit of technology from which I learned much.

He reminds me of a guy I knew, very smart, who hated C++ and it’s object support. He coded in C instead. However, in order to make robust modern software he had to do many of the same things the C++ compiler did, not realizing that C++ itself originated with people writing code exactly the way he did who said “gosh, shouldn’t my compiler be doing this for me?”. Properly used, OOP does the same thing. It can, of course, be used in the negative ways he describes, but that’s what you get when you use a sharp knife (and it’s not like I haven’t seen the equivalent out of pure Lisp programmers).

Post a comment