On 18/07/12 14:05, Steven D'Aprano wrote:
On Wed, 18 Jul 2012 01:46:31 +0100, Andrew Cooper wrote:Take for example a Linux system call handler. The general form looks a little like (substituting C for python style pseudocode) if not (you are permitted to do this): return -EPERM if not (you've given me some valid data): return -EFAULT if not (you've given me some sensible data): return -EINVAL return actually_try_to_do_something_with(data) I’m feeling a bit fed uI’m feeling a bit fed uI’m feeling a bit fed u How would you program this sort of logic with a single return statement?That's not terribly hard. if not (you are permitted to do this): result = -EPERM elif not (you've given me some valid data): result = -EFAULT elif not (you've given me some sensible data): result = -EINVAL else: result = actually_try_to_do_something_with(data) return result A better example would involve loops. I used to hate programming in some versions of Pascal without a break statement: I needed a guard variable to decide whether or not to do anything in the loop! # pseudo-code for i in 1 to 100: if not condition: do_something_useful() Even with a break, why bother continuing through the body of the function when you already have the result? When your calculation is done, it's done, just return for goodness sake. You wouldn't write a search that keeps going after you've found the value that you want, out of some misplaced sense that you have to look at every value. Why write code with unnecessary guard values and temporary variables out of a misplaced sense that functions must only have one exit?
Object Oriented programming is all about encapsulating human concepts in a way that makes sense to human beings. Make no mistake, it is NEVER the case that a software system is written for any other reason than to serve human beings. OO is more than just the mechanics of writing code, it's a state of mind.
OO was 'invented' to address the many problems that beset increasingly complex software systems. The main problem was maintainability. Encapsulating a concept in a clear and concise way makes the code easier to understand. Sometimes this means writing code that is not 'optimal' for the machine. Good code should be readable as well as efficient but I contend that it is better to write something that is clear, concise and well encapsulated than always go for the 'meanest dog in the scrapyard' approach where a developer is determined to write unreadable code that shows how jolly clever he is. More often than not he is forced to admit six months down the line that he has no idea what his code does as he 'forgot' to comment it.
I speak from bitter experience. This approach works for me. I have thousands of lines of code operating every day 'in the wild', everything from flight booking systems to real time odds arbitrage. Any developer who 'gets' OO can read and modify my code and I am very proud of this fact ... and I have never been forced to admit that I don't know what I wrote six months ago.
If you are writing embedded systems that must have a very limited memory footprint then there is a case for conciseness over readability but even then it has to be maintainable
Python looks like an interesting language and I will certainly spend time getting to know it but at the moment it seems to me that calling it an Object Oriented language is just plain misleading.
There, I've said it, trolls and flamers beware, I take no prisoners. Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
