Comment On Self Documenting

Some Damn Yank:

Rodd:

Matt Westwood:

You're doing it wrong. A phone number should be defined by a class in its own right with its own internal validation. If you're holding it as a string and banking on the class you're holding it in validating it, you've got it backarsewards.

Obviously. And inside that class, you store a PhoneNumberDigitArray class containing 9 instances of the PhoneNumberDigit class.

You're' all wrong. Assuming the US telephone system developed by TPC (The Phone Company, for those of you who somehow missed "The President's Analyst"), what the public refers to as a "phone number" is actually a concatenation of three numbers: the Area Code (3 digits), the Central Office (exchange) code (3 digits), and the Subscriber Number (four digits).

So you need an AreaCode class, a CentralOffice class, and a SubscriberNumber class to go along with your PhoneNumberDigit class.

Some Damn Yank:

So you need an AreaCode class, a CentralOffice class, and a SubscriberNumber class to go along with your PhoneNumberDigit class.

Matt Westwood:

Only if you've allowed a subclass of the PhoneNumber class to be AmericanPhoneNumber

Your Name:

gratuitous_arp:

Your Name:

KattMan:

CAPTCHA:sino:

Sorry that was an offtopic rant. Also I hate setter and getter functions that only consist of "this.value = value" or "return this.value". Anyone who creates a language where they are necessary is a dickweed arsehole.

Look into encapsulation and the "law" of demeter and you will know why these simple get/set methiods exist. It's not the language that requires them, you can make your variables public, but then the thing that owns them has no control over when and how they are updated.

No, this is an artifact of the languages you use, and you're so used to it that you can't imagine it any other way. Look at the way Python, for instance, implements "properties". You have a public variable, and then later, if you need access to that public variable to go through a method, you can change it to do that transparently to the code that uses that class doesn't need to change.

As KattMan said, you can do the same thing in C++ using a public variable and later writing a get function for it if desired. People don't do this because it's bad design -- in any language -- for both of the reasons given by KattMan. As you know, in Python, there is an idiom to denote properties that should not be accessed directly by adding a leading underscore to the property's name. This access control "suggestion" is used to provide the private membership given by C++ (though not enforcing it) while retaining the language's flexibility. In PEP-8, Guido gives further examples of why this is a good idea. See: http://www.python.org/dev/peps/pep-0008/#designing-for-inheritance

If you're writing small Python scripts it doesn't really matter (as long as you *know* they'll stay small). If you're writing large programs, it does matter.

Only in C++ and the languages derived from it (e.g. Java) do you see everyone "defensively" creating getters and setters for everything right off the bat.

You're talking about defensive programming, something that is hopefully common in code written in any language. Setters are just as important in Python as they are in C++ if you want any kind of assurance that anything valid is getting passed to your object. Getters hide implementation details. Other than taking some extra time to write, what specifically do you find undesirable about get/set functions?

No, you're still not getting it.

Look, in C++ or Java, you have a class and some information encapsulated in it.

class foo

{

   //...

   public:

      int bar;

}

Now, code uses this objects of this class and accesses the variable foo.bar directly. It's all good until you decide that accesses to foo.bar need to do something else -- maybe there's some internal counter you want to increment or you want to validate or log or you want to calculate bar on the fly or whatever. Now all the code that USES class foo needs to be rewritten to call foo.getBar() and foo.setBar(int newBar). After getting bitten by this once, from then on you always make all member variables private and waste time (both writing and compiling) and code size (both source and, if your optimizing compiler isn't sufficiently good, binary size) on getters and setters that might not actually be necessary (e.g. if in the lifespan of your project they never do anything but act as passthroughs for the private member variable, you did that work for nothing).

In a language with properties (or whatever the feature ends up getting called), this changeover is transparent to the code using class foo. So, you start with a class, as before, with a public member variable.

class foo:

   def __init__(self):

      self.bar = 0

Other code accesses bar directly.

obj = foo()

obj.bar = 10

Later, you change your mind and want foo.bar to go through a getter or whatever. So you implement it as a property in the foo class definition.

class foo:

   def __init__(self):

      self._private_bar = 0

   def set_bar(self,bar):

      self._private_bar = 0

      #insert side effects here

   def get_bar(self):

      #insert side effects here

      return self._private_bar



   bar = property(set_bar, get_bar)

That last line there is key. Now, the code USING the foo class, the stuff you already wrote, doesn't need to change. You don't even need to recompile it if all you have is the compiled bytecode! All those calls to directly access foo.bar are transparently converted into function calls to the property. (The syntax is ugly by Python standards but that still puts it head and shoulders above C++.) Because of this, you can have publicly accessible member variables and only write getters and setters when you actually need them, rather than write a bunch of pointless ones right off the bat just in case they become necessary later. (As a useful bonus, you can tell at a glance if some Python code you're looking at was written by someone who doesn't really know the language, because it will have trivial getters and setters everywhere.)

Do you get it yet?

eric:

Perhaps he expected validation checking to be more complicated, but it didn't end up that way.

Jay:

clive:

If you can't rename your function when you change what it does, you've got serious problems with your codebase or processes anyway.

Well, if the function is only used within one project, and only used in standard ways, then at least some IDEs -- Eclipse, for example -- can make renaming it pretty easy. I've only used a handful of IDEs so I can't say if this is a common feature.

In any case, if a function is used across many projects, e.g. it's part of library, then this might not be quite so simple: You'd have to identify every project that uses it and update all of them.

If you use reflection to access functions, renaming it may not be trivial. Where does the system get the name from? A simple hard-coded string? An XML file? A database record? You'd have to investigate all these possibilities and more. Even if this particular function is never accessed via reflection, you would have to know that or be able to prove that.

If it's part of a published API used by many people outside your organization, then changing a function name should be a step taken with extreme caution if you don't want to have lots of unhappy clients.

What does a 50 characters identifier has to do with memory? Much less performance?

Compiler theory indeed....

The length of a variable name is a particularly silly thing to criticize on the basis of performance, as it will be tokenized almost immediately by the compiler or interpreter. The only machine resource it wastes is developers' disk space.

me:

I remember when Engineers had to have degrees and built tangible things.

Some Damn Yank:

Some Damn Yank:

So you need an AreaCode class, a CentralOffice class, and a SubscriberNumber class to go along with your PhoneNumberDigit class.

From a practical standpoint this actually isn't a bad idea.

gratuitous_arp:

Your Name:

[...]
Later, you change your mind and want foo.bar to go through a getter or whatever. So you implement it as a property in the foo class definition.

class foo:

   def __init__(self):

      self._private_bar = 0

   def set_bar(self,bar):

      self._private_bar = 0

      #insert side effects here

   def get_bar(self):

      #insert side effects here

      return self._private_bar



   bar = property(set_bar, get_bar)

That last line there is key. Now, the code USING the foo class, the stuff you already wrote, doesn't need to change. You don't even need to recompile it if all you have is the compiled bytecode! All those calls to directly access foo.bar are transparently converted into function calls to the property. (The syntax is ugly by Python standards but that still puts it head and shoulders above C++.) Because of this, you can have publicly accessible member variables and only write getters and setters when you actually need them, rather than write a bunch of pointless ones right off the bat just in case they become necessary later. (As a useful bonus, you can tell at a glance if some Python code you're looking at was written by someone who doesn't really know the language, because it will have trivial getters and setters everywhere.)

Do you get it yet?

Ah, I thought you were using "properties" as a general description for class attributes -- I wasn't aware that Python had a property keyword.

def makebold(fn):

    def wrapped():

        return "<b>" + fn() + "</b>"

    return wrapped



def makeitalic(fn):

    def wrapped():

        return "<i>" + fn() + "</i>"

    return wrapped



@makebold

@makeitalic

def hello():

    return "hello world"



print hello() ## returns <b><i>hello world</i></b>

Kuba:

A decorator is just a function, only that it expects a callable object (say, a function) as an argument, and should return a yet another callable object.

Geoffrey T. Buchanan:

That 50 character length function name is surely a sign of the times. I learned my craft back in the day when software engineering was a serious discipline, before the kids turned up with their IPad/Facebook/Web2.0 bullshit.

Back then 16kb was considered a LUXURY and we had to learn to write highly efficient and compact code so that it would PERFORM. Well I am sure you've all heard this before and I don't want to bang on about some "golden age" - it wasn't perfect I am not saying that. It's just that an engineer who wasted programme memory so frivolously creating a 50 character identifier back then would have been fired on the spot.

I suppose modern businesses tolerate the complete waste of resources today because computers have got more powerful and the customer rarely complains. But you have to wonder how much faster typical software would run if it was written as per the old ways. There's also a slippery slope in play - out there now are a load of upstart "programmers" who are making all the software we use but they have no idea about how computers work let alone basic compiler theory. And people wonder why there are so many security holes and viruses in software these days...

/rant

tox:

Geoffrey T. Buchanan:

That 50 character length function name is surely a sign of the times. I learned my craft back in the day when software engineering was a serious discipline, before the kids turned up with their IPad/Facebook/Web2.0 bullshit.

Back then 16kb was considered a LUXURY and we had to learn to write highly efficient and compact code so that it would PERFORM. Well I am sure you've all heard this before and I don't want to bang on about some "golden age" - it wasn't perfect I am not saying that. It's just that an engineer who wasted programme memory so frivolously creating a 50 character identifier back then would have been fired on the spot.

I suppose modern businesses tolerate the complete waste of resources today because computers have got more powerful and the customer rarely complains. But you have to wonder how much faster typical software would run if it was written as per the old ways. There's also a slippery slope in play - out there now are a load of upstart "programmers" who are making all the software we use but they have no idea about how computers work let alone basic compiler theory. And people wonder why there are so many security holes and viruses in software these days...

/rant

What have identifiers to do with performance.

Joe:

What does a 50 characters identifier has to do with memory? Much less performance?

Compiler theory indeed....

For compiled languages, shorter variables and terser comments lead to smaller source files and therefore faster floppy disk access.

CAPTCHA:sino:

Then you try to get an MD5 hash in Python and you have to do this:

m = hashlib.md5()

m.update("mahstring")

hash = m.hexdigest();

Hey! Since MD5 is a function (string -> hash), why not make it, you know, a function! (yes you can do it in one line but that's not the point)

KattMan:

Matt Westwood:

You're doing it wrong. A phone number should be defined by a class in its own right with its own internal validation. If you're holding it as a string and banking on the class you're holding it in validating it, you've got it backarsewards.

Wow, did you even read what I said then read what you said? Can you even get the concept in your head without forgetting some other rudimentary thought?
Let's hope you don't forget how to wipe your own nose when I say it this way.
Yes you have a phone number class, but you need to set the value in it somewhere, and that is where you validate. You essentially just said what I did, because the setter you use to get your phone number into your phone number class is where you should have your validation call, not someplace later in the class, this is part of what setters are for! Validate when it comes in, not sit on it and maybe validate later.

Your Name:

Botia:

I remember when methods were verbs.

I remember when programmers were engineers.