I'm afraid the normal way of creating a Method instance is circuitous
and a bit hard to write:
a_method = object.method(:method_name)
I find the way of obtaining a function/method object in Python is so
easy, for example, "str.split()" returns a list, while "str.split"
(without parentheses) returns a method object. However, parenthesis in
Ruby is always optional, so this road is blocked.
Well, how about "object.\method" style? You can type "str.\split" to get
"str.method(:split)".
The reasons are:
1. It makes people happy, writing less code, and no harm to readability.
2. "\" is not a frequently used token. It can only be used in strings,
regexps (or any else?). I think using this token leads to no ambiguity.
3. "\" is like Perl's referrence symbol. In Perl, you can use "$f =
\&func;" to make a referrence to the function. In Ruby, "&" seems
unnecessary.
4. It enhances the consistency of the language syntax. There are two
correlative methods "Object#send" and "Object#method", but...
Um, and how often do you need to get a method, instead of just calling
it right there? Okay, there are some situations (maybe you need to get
some module method and pass it as a block to something else - although
that's the most sensible idea I had, and it's already far-fetched),
but overall I think it's unnecessary
By the way, \ is already used to continue a line of code over multiple
"physical" lines (in other words: to escape newline characters).
Last but not least, while taking features from Perl is cool (they
created some awesome stuff), complexity of it's syntax is just about
the worst thing about it.
Personally I find the \ character troublesome: it reminds me too much about escaping something, which IMO has no analogy here.
I'm already recovering from eye cancer due PHP adopting "\" as the namespace separator ... horrible decision, if you ask me.
I haven't long really worked with/in C, but "&" as the operator for getting the address of an something would fit the analogy to get the instance of an method:
str.&split
But honestly I don't feel a necessity for it anyway.
- Markus
···
On 25.09.2011 16:40, Joey Zhou wrote:
Well, how about "object.\method" style? You can type "str.\split" to get
"str.method(:split)".
While I'm not sure how I feel about this particular syntax, I think that
better support for getting methods would have some fairly profound changes
to Ruby code. Right now we think this isn't really worth it, because we
don't really do things like this, because the syntax is awkward. But if it
were easier, I think we'd see a lot more of it.
An example from yesterday, I wrote `File.open csv_name,
&MembersFromCSV.method(:populate)`
And I honestly almost took it out (and still might), because even though I
think this is the right way to do it, it's cumbersome and you kind of have
tolook at it and think about things for a while. The equivalent is
`File.open(csv_name) { |file| MembersFromCSV.populate file }` but it's kind
of obnoxious that you have to create a superfluous block that does nothing
but forward its arguments to the real target when you could pass the real
target instead of the block if there were a bit better support for this sort
of thing.
···
On Sun, Sep 25, 2011 at 9:40 AM, Joey Zhou <yimutang@gmail.com> wrote:
I'm afraid the normal way of creating a Method instance is circuitous
and a bit hard to write:
a_method = object.method(:method_name)
I find the way of obtaining a function/method object in Python is so
easy, for example, "str.split()" returns a list, while "str.split"
(without parentheses) returns a method object. However, parenthesis in
Ruby is always optional, so this road is blocked.
Well, how about "object.\method" style? You can type "str.\split" to get
"str.method(:split)".
The reasons are:
1. It makes people happy, writing less code, and no harm to readability.
2. "\" is not a frequently used token. It can only be used in strings,
regexps (or any else?). I think using this token leads to no ambiguity.
3. "\" is like Perl's referrence symbol. In Perl, you can use "$f =
\&func;" to make a referrence to the function. In Ruby, "&" seems
unnecessary.
4. It enhances the consistency of the language syntax. There are two
correlative methods "Object#send" and "Object#method", but...
I had a strong enough reaction to this that I started responding evne
before I knew what I wanted instead. Yes, it's somewhat obnoxious that
you have to create a superfluous block to forward the argument on.
It's less obnoxious to take the method and use #to_proc (via the &),
and it's partially syntax that's a problem there, or at least that it
looks odd because we're not used to it. But I couldn't think what
would be better. I'd like to see something like `File.open csv_name,
MembersFromCSV.method(:populate)`, but that could have its own
problems.
You know, I'm not at all a fan of stabby proc, and maybe more so now
that the arrow could be used here. Something like `File.open csv_name,
-> MembersFromCSV.method(:populate)` has some merit as far as looks
go. Maybe? Am I crazy?
Actually, I think I'm crazy. Just get used to & and #to_proc.
···
On Sep 28, 8:08 pm, Josh Cheek <josh.ch...@gmail.com> wrote:
While I'm not sure how I feel about this particular syntax, I think that
better support for getting methods would have some fairly profound changes
to Ruby code. Right now we think this isn't really worth it, because we
don't really do things like this, because the syntax is awkward. But if it
were easier, I think we'd see a lot more of it.
An example from yesterday, I wrote `File.open csv_name,
&MembersFromCSV.method(:populate)`
And I honestly almost took it out (and still might), because even though I
think this is the right way to do it, it's cumbersome and you kind of have
tolook at it and think about things for a while. The equivalent is
`File.open(csv_name) { |file| MembersFromCSV.populate file }` but it's kind
of obnoxious that you have to create a superfluous block that does nothing
but forward its arguments to the real target when you could pass the real
target instead of the block if there were a bit better support for this sort
of thing.