07:52 pm, 24 Feb 05
ruby wart
I'm still a huge Ruby fan, and I really do like the way that you call argumentless functions without parens and the way that affects the rest of the language.
But the way procs and blocks are different is lame:
I run into a similar pattern all the time writing Python at work and it's equally lame:
So my code ends up littered with more readable but still lame [x.foo() for x in list] over and over.
Perl worked around it with the implicit variable, which makes the language-purity-types shudder but I think is a pretty clever way to design it.
% perl -e '$,=":"; print map { $_ + 1 } (1,2,3)'
2:3:4
But the way procs and blocks are different is lame:
["a", "b c"].map { |x| CGI.escape(x) }
=> ["a", "b+c"] # the result i want
["a", "b c"].map(CGI.escape)
ArgumentError: wrong number of arguments (0 for 1)
p = Proc.new { |x| CGI.escape(x) }
["a", "b c"].map(&p)
=> ["a", "b+c"]
["a", "b c"].map(&CGI.escape)
ArgumentError: wrong number of arguments (0 for 1)I run into a similar pattern all the time writing Python at work and it's equally lame:
>>> map(upper, ['abc', 'def']) # i know this won't work Traceback (most recent call last): File "<stdin>", line 1, in ? NameError: name 'upper' is not defined >>> map(lambda x: x.upper(), ['abc', 'def']) ['ABC', 'DEF']
So my code ends up littered with more readable but still lame [x.foo() for x in list] over and over.
Perl worked around it with the implicit variable, which makes the language-purity-types shudder but I think is a pretty clever way to design it.
% perl -e '$,=":"; print map { $_ + 1 } (1,2,3)'
2:3:4
map(str.upper, ['abc', 'def'])
Additionally operators can be used from the operator module.
I think that's one of the reasons why in python you have to explicitly name "self" (or whatever you want to name it) as the first argument of a member method. The dot operator is just a short hand that passes the object as the first parameter. E.g., in a custom class, I can always do something like:
class Foo: def bar(self): print 'foobar' f = Foo() Foo.bar(f) # same as doing f.bar()class Base: def f(self): return 'base' class Derived: def f(self): return 'derived' foo = Derived() map(Base.f, [foo])would probably produce ['base'] and not ['derived']. This would be a more interesting demo if there were multiple different derived classes.
More formally: do I get dynamic dispatch using this technique or is the class fixed?
class Base: def f(self): if self.__class__.__name__ != 'Base': return self.f() return 'base' class Derived(Base): def f(self): return 'derived' foo = Derived() print map(Base.f, [foo])map(lambda c:c.f(),[foo]), right?What bugs me more is that
printcan't be used in place of (or even in) a lambda expression! You have to go withsys.stdout.writeor something.{ something }— is a closure (and an object of typeCode). And of course there's even more of that "topic" behavior going on, a little more formalized than in previous vesions. I'm doing round n+1 now of reading the specs again and my mind is hurting less than the last time.Does this count as just-as-ugly?
This may not work:but this does:["a", "b c"].map(&CGI.method("escape")) => ["a", "b+c"]