1. function definitions being constrained to classes has nothing to do with OOP
2. static functions or members have absolutely nothing to do with OOP
I see a lot of criticism of OOP, but when I get to reading the details, it's all about Java's flavor of OOP.
What is a class or static method? These are OO constructs and require additional mental overhead when learning.
You don't need to pass parameters to your car to start it. You don't need to force yourself to only focus on the recipe (scope) when making dinner.
None of these things map very well with the real world and could also be considered additional mental overhead when learning. You don't need to know how to code to learn best known practices in building software.
Learn things one at a time; "best practices" can wait til you can demonstrate why it is a best practice. Why should I make a function? Until you actually face the problems that abstractions are used to solve, learning them is confusing and difficult.
This also happens in math quite a bit. There is a knowledge gap when teaching concepts like derivatives for the first time. So we are told to initially ignore details while learning.
In my experience, it's best not to delay learning the details. You don't have a real understanding of something until you understand the details.
However that makes even less of a case for Python.
You're right: static methods are not an OOP construct. They're a hack to allow the user to break out of the straitjacket at a specific moment, because it's impossible to write anything but a library otherwise.
The issue, thus, is that Java requires a beginner to learn a paradigm-breaking manuever as a basic operation. "Java is a glorious OOP language. If you want to write anything that's pure Java, though, here's how you stop being OOP in order to do so."
(Also, for the record: I like OOP. I like Ruby specifically because it makes OOP so natural and honest.)
I like how Rubyists/Pythonists jump to criticize Java, but they don't know the first thing about OOP.
I don't even use Java but these critiques are retarded, seriously.
Technically, such methods are not methods. They are functions. And the distinction between a "static method" and a function is completely arbitrary, dictated by a completely arbitrary limitation of how bytecode is organized on top of the JVM (e.g. class-files instead of package files) and by somebody's flawed vision that all function declarations should happen inside a class, even if those functions are not methods.
And actually, what I've said in my first sentence is wrong. "this" may not be passed to static methods, as classes are not objects, however classes are some sort of pseudo-objects that are special for the JVM and "this" does exist in certain contexts, like when declaring a "static synchronized" method, which does use this pseudo-object for acquiring an intrinsic lock. Also this pseudo-object does have a constructor.
So you see, classes play the role of packages for static members and methods, except that in a language like Python, packages are objects themselves, whereas in Java they aren't. Plus, if you look at classes with static members as being packages, they are retarded packages, because you can't pass them around as values, you can't override imports and so on.
I can keep going btw.
I agree that they are just functions, but no one is trying to "hack" or to break encapsulation. They could have used packages instead, yes... But having them inside classes is pretty convenient as this allows us to have a better syntax.
Oh and not being able to pass classes around is a language-specific thing, so you can't really use that as an argument against static methods.
You say it's about "Java's flavor of OOP." That's 100% true. So, how do you explain Java's flavor of OOP — which is necessary to explain why Java does certain things that would otherwise seem like arbitrary invocations — without explaining OOP at least in part? As soon as the beginner sees the word "class" or "public" they'll be forced to either contextualize those concepts or take them as arbitrary strings one puts into their program because Magic™.
The OC's point was that Java forces people to grapple with certain OOP concepts, even if those concepts are particular to Java's flavor of OOP.
You're both just talking past each other.
1. Instantiate Object.
2. Invoke Method.
3. Get or modify attribute.
4. Do some introspection (even if the term is not used)
1. What is an object?
2. What does it mean to "instantiate" an object?
3. What is a method?
4. What does it mean to "invoke" a method?
5. What is an attribute?
6. What does it mean to "get" an attribute?
7. What does it mean to "modify" an attribute?
8. What is introspection?
Here is an example that instantiates an object, introspects, gets an attribute, introspects again, and invokes a method. It's 11 commands.
>>> import requests
>>> def introspect(obj):
... for x in dir(obj):
... print x
...
>>> request_object = requests.get('https://news.ycombinator.com/item?id=6919275')
>>> introspect(request_object)
__bool__
__class__
__delattr__
__dict__
[...]
request
status_code
text
url
>>> request_object.status_code
200
>>> request_object.url
u'https://news.ycombinator.com/item?id=6919275'
>>> introspect(request_object.url)
__add__
__class__
__contains__
__delattr__
[...]
title
translate
upper
zfill
>>> request_object.url.upper
<built-in method upper of unicode object at 0x29a3330>
>>> request_object.url.upper()
u'HTTPS://NEWS.YCOMBINATOR.COM/ITEM?ID=6919275'
Some interested students might ask "What's an object, under the hood?" and "how can I create my own classes?" That's when you can introduce them to classes (http://docs.python.org/2/tutorial/classes.html). If they're fine with the intuitive understanding that comes with performing examples like the one above, leave them be. Don't inflict OOP principles they don't need to know yet.
I think the example code you gave is fine, but does not actually answer those questions. The mind of a beginner is like a map of a country with unmarked or incorrectly-marked territories. They don't know where the relevant boundaries between concepts/territories are or even how to begin drawing them. They can't differentiate between important and unimportant details. Like a child who is just learning how to speak, they see the differences in everything and every difference matters. That is, to a beginner, if there's a difference it's important.
Here's a Ruby example. I've given many students this code:
my_name = "Jesse"
my_age = 30
puts "Hello! My name is #{my_name} and I am #{my_age} years old."
When I look at your code, I see a few dozen opportunities for students to form exactly these kinds of beliefs, which is one of the challenges of writing effective curriculum. This is doubly difficult when there isn't a teacher nearby to catch these mistaken beliefs as they're formed or shortly thereafter. In most online or "single player" learning experiences students will form a web of incoherent, confusing beliefs, not even know they're doing it, and carry on for much longer than they would otherwise.
For example, I'm assuming the "u" prefix on those strings in Python is a way to indicate that they are unicode strings. If a student already knows that strings exist and sees that output, it's likely that a large minority of students will assume that u'HTTPS://NEWS.YCOMBINATOR.COM/ITEM?ID=6919275' does NOT represent a string but something else entirely. They will then carve out a hole in their schema of the world where "u-things" go and it will never occur to them that doing something like
request_object.url == 'https://news.ycombinator.com/item?id=6919275'
Maybe we're saying the same thing, but I hope you get my point. This has to do with the particular way most beginners in any subject interact with new information.
Probably, my example was off-the-cuff, and I think I may have misinterpreted the original intent of your post a bit. I'm still not sure which "side" of the discussion you're on, though. (Teach classes and OOP sooner vs. later). For my part I definitely favor "leave it for later"
In Zed Shaw's "Learn Python The Hard Way" book, after raving about dictionaries in section 39, he barely uses them for the remainder of the book, while spending a lot of time on classes and class heirarchies. It's a succinct (and very successful, I believe) introduction to OOP and Python's features so I can't vehemently criticize it, but I do wonder what the last few chapters would have looked like with a more flat function + dictionary approach.
I understand the issue of little details stuff, for sure. I've never taught python but I have taught bash. Gave you an upvode for for the second paragraph, I found it to be an unusually eloquent way to describe the learning experience. I've never been able to express that idea so well.
It doesn't?
JavaScript, for example, is an OOP language without classes per se. Indeed, many JavaScript programmers avoid what little built-in class-like behavior JavaScript has and implement their own class definition/inheritance/instantiation mechanisms via things like Object.extend.
And although it's rare, one can define "singleton" methods directly on objects in Ruby, too:
animal = "Dog"
# This is now defined only on the animal object
# and no other String instance
def animal.bark!
"Woof woof!"
end
animal # => "Dog"
animal.class # => "String"
animal.bark! # => "Woof woof!"
This is the point I understood the GP to be making.
The OP actually did a very clear job of distinguishing between Python- and Java-style OOP. I think you're the one cherry-picking his Java example and then extrapolating that to refer to all of OOP.