b) form_for(Model.new) is great. That's why I've successfully gotten it added in the next version of Pylons. SQLAlchemy is a zillion times more powerful than ActiveRecord, but if you need hand-holding, you can use an AR-ish layer on top of it, such as Elixir: http://elixir.ematia.de/trac/wiki
I've been using Rails for a year and a half, and every time I get a chance to work in Pylons, it's like a breath of fresh air.
It seems to me that the Python fans in this argument are conflating two separate concerns here:
1) Requiring self for access to member variables and methods is a great idea, and is why Hungarian notation like m_foo for a member called foo is popular in languages that don't require it. Ruby does this with @, which is also nice because it's short; I know people who use m_foo in C++ because it's shorter than this.foo, and while I don't agree with them, I can kind of see how a shorter prefix would be nice. But Ruby does lose points in my book for not requiring self/@ for access to object-local methods.
2) Requiring self as an explicit parameter in method definitions confuses the living crap out of newbies. I've seen this several times in the real world. Try explaining it to someone who doesn't yet understand OOP sometime, it's a disaster. On the other hand, making self a magic keyword that gets you the present object, the way Java and C++ handle this, is less confusing, less typing, and has a perfectly nice symmetry between the scope of the definition (method foo is declared on objects of class Bar) and the namespace visible in the call (bar.foo() calls a method foo on the bar object). In contrast, self looks like an explicit parameter in the definition, but doesn't look that way in the call. If you want def foo(self), I think the consistent thing is to do like CLOS and call it like foo(bar) rather than bar.foo(). If you want bar.foo(), something like def self.foo() would be less confusing.
Reason 1: Because they make code easier to read. Purely subjective. I strongly disagree; Ruby is more concise, and ivar access is clearly seperate from method calls.
Reason 2: Because Python will allow you to "cast" self to a superclass to grant explicit access to its variables. Ruby doesn't have this problem.
Reason 3: Because Python would rather overload the keyword "self" than allocate a sigil (@).
Comments
a) There are excellent reasons why Python requires passing 'self' to each method. The article linked to three of them; I'll just link to one: http://effbot.org/pyfaq/why-must-self-be-used-explicitly-in-...
b) form_for(Model.new) is great. That's why I've successfully gotten it added in the next version of Pylons. SQLAlchemy is a zillion times more powerful than ActiveRecord, but if you need hand-holding, you can use an AR-ish layer on top of it, such as Elixir: http://elixir.ematia.de/trac/wiki
I've been using Rails for a year and a half, and every time I get a chance to work in Pylons, it's like a breath of fresh air.
It seems to me that the Python fans in this argument are conflating two separate concerns here:
1) Requiring self for access to member variables and methods is a great idea, and is why Hungarian notation like m_foo for a member called foo is popular in languages that don't require it. Ruby does this with @, which is also nice because it's short; I know people who use m_foo in C++ because it's shorter than this.foo, and while I don't agree with them, I can kind of see how a shorter prefix would be nice. But Ruby does lose points in my book for not requiring self/@ for access to object-local methods.
2) Requiring self as an explicit parameter in method definitions confuses the living crap out of newbies. I've seen this several times in the real world. Try explaining it to someone who doesn't yet understand OOP sometime, it's a disaster. On the other hand, making self a magic keyword that gets you the present object, the way Java and C++ handle this, is less confusing, less typing, and has a perfectly nice symmetry between the scope of the definition (method foo is declared on objects of class Bar) and the namespace visible in the call (bar.foo() calls a method foo on the bar object). In contrast, self looks like an explicit parameter in the definition, but doesn't look that way in the call. If you want def foo(self), I think the consistent thing is to do like CLOS and call it like foo(bar) rather than bar.foo(). If you want bar.foo(), something like def self.foo() would be less confusing.
Reason 1: Because they make code easier to read. Purely subjective. I strongly disagree; Ruby is more concise, and ivar access is clearly seperate from method calls.
Reason 2: Because Python will allow you to "cast" self to a superclass to grant explicit access to its variables. Ruby doesn't have this problem.
Reason 3: Because Python would rather overload the keyword "self" than allocate a sigil (@).