I think the name method is probably a poor choice b/c “shadow
methods” (as I call them) do the same thing as their non-shadow forms.
Eg. #send and #send, #id and #id, etc. But #method is an
exception since #method currently returns a Method object given the
name, not the name of the current context.
T.
Hi,
In message “Re: About 1.9 #method feature.”
on Mon, 3 Jul 2006 23:33:54 +0900, [email protected] writes:
|I think the name method is probably a poor choice b/c “shadow
|methods” (as I call them) do the same thing as their non-shadow forms.
|Eg. #send and #send, #id and #id, etc. But #method is an
|exception since #method currently returns a Method object given the
|name, not the name of the current context.
It’s not conjunction with send etc. but with FILE and
LINE. Besides that, I am no longer fond of send and id,
I’d rather like to remove them if it’s possible. Use invoke_method
and object_id respectively instead.
matz.On Tue, 4 Jul 2006, Yukihiro M. wrote:
It’s not conjunction with send etc. but with FILE and
LINE. Besides that, I am no longer fond of send and id,
I’d rather like to remove them if it’s possible. Use invoke_method
and object_id respectively instead.
can we also have
METHOD # just the name
for symmetry?
-a
Hi –
On Tue, 4 Jul 2006, Yukihiro M. wrote:
It’s not conjunction with send etc. but with FILE and
LINE. Besides that, I am no longer fond of send and id,
I’d rather like to remove them if it’s possible. Use invoke_method
and object_id respectively instead.
Speaking of send: is the ‘funcall’ name definite? Are you still
interested in hearing arguments against it? 
David
Hi,
In message “Re: About 1.9 #method feature.”
on Tue, 4 Jul 2006 00:14:13 +0900, [email protected] writes:
|can we also have
|
| METHOD # just the name
|
|for symmetry?
In addition to method? H mm, maybe. I am not sure how much
symmetry buys us here.
Since I don’t like capitals in general, it’s less chance to remove
method. I just used FILE etc. for consistency with CPP.
matz.Hi,
In message “Re: About 1.9 #method feature.”
on Tue, 4 Jul 2006 00:31:03 +0900, [email protected] writes:
|Speaking of send: is the ‘funcall’ name definite? Are you still
|interested in hearing arguments against it?
Do you have a proposal for any alternatives? By the way, have you
noticed the alias “invoke_functional_method”?
matz.On 7/3/06, Yukihiro M. [email protected] wrote:
It’s not conjunction with send etc. but with FILE and
LINE. Besides that, I am no longer fond of send and id,
I’d rather like to remove them if it’s possible. Use invoke_method
and object_id respectively instead.
Any chance we can get #invoke_method added to Ruby 1.8.5 so that we
can use it instead of #send? I’ve got a lot of #send calls in
places. It would also be useful to know which of these sorts of things
will be used for private calls (e.g., I have code that must be able to
call methods that are otherwise private).
-austin
On Tue, Jul 04, 2006 at 12:39:12AM +0900, Yukihiro M. wrote:
Hi,
In message “Re: About 1.9 #method feature.”
on Tue, 4 Jul 2006 00:31:03 +0900, [email protected] writes:|Speaking of send: is the ‘funcall’ name definite? Are you still
|interested in hearing arguments against it?Do you have a proposal for any alternatives? By the way, have you
noticed the alias “invoke_functional_method”?
hmmm the link between “might be called externally despite being private”
and
“functional” is subtle, to say the least;
#invoke_private_method seems much clearer (even if inaccurate) and is
nearly
as long if you want to discourage its use.
Hi –
On Tue, 4 Jul 2006, Yukihiro M. wrote:
Hi,
In message “Re: About 1.9 #method feature.”
on Tue, 4 Jul 2006 00:31:03 +0900, [email protected] writes:|Speaking of send: is the ‘funcall’ name definite? Are you still
|interested in hearing arguments against it?Do you have a proposal for any alternatives? By the way, have you
noticed the alias “invoke_functional_method”?
What bugs me is the mixing of two different paradigms: message-sending
and method-calling. I know they are closely related But it seems
odd to use both paradigms for, essentially, the same thing:
obj.send(:meth)
obj.funcall(:meth)
It feels like this symbolic operation should be understood either as
message-sending (my preference) or method-calling, but not alternate
between the two. And the names don’t encapsulate the difference
between the two operations (private methods included or not).
I haven’t noticed invoke_functional_method. I admit I’m still unclear
on the (new?) use of the notion of ‘function’ in addition to
‘method’… How do you characterize a functional method, in this
context?
David
On Tue, 4 Jul 2006, Yukihiro M. wrote:
In addition to method? H mm, maybe. I am not sure how much symmetry
buys us here.
one less trip to the docs! 
stuff like that is hard to remember.
Since I don’t like capitals in general, it’s less chance to remove
method. I just used FILE etc. for consistency with CPP.
with you on both counts. maybe a meta-method to return all the info:
where = where
p where[0].file #=> same as FILE
p where[0].method #=> same as method
p where[0].line #=> same as LINE
p where[0].binding #=> same as binding
p where[1].file #=> same as FILE
p where[1].method #=> same as method
p where[1].line #=> same as LINE
p where[1].binding #=> same as binding
p where[2].file #=> same as FILE
p where[2].method #=> same as method
p where[2].line #=> same as LINE
p where[2].binding #=> same as binding
basically i’m proposing a ‘caller’ like interface which returns an array
of
objects having all the ‘location’ information, including scope/binding.
this
could be amazingly useful.
regards.
-a
Hi –
On Tue, 4 Jul 2006, Mauricio F. wrote:
noticed the alias “invoke_functional_method”?
hmmm the link between “might be called externally despite being private” and
“functional” is subtle, to say the least;
#invoke_private_method seems much clearer (even if inaccurate) and is nearly
as long if you want to discourage its use.
I think it’s inaccurate to the point of really not being usable.
I admit I’m still a fan of send/send! but I guess they’re long gone
David
Hi –
In the old days, I used to herald the appearance of every 10K’th
message on this list. I don’t do that any more… but I think message
#200000 is worth taking note of. Yes, yes, the count is probably off
due to this or that glitch over the years. But it’s still cool,
especially because in spite of its growth and growing pains, this list
is still extraordinarily useful and collegial.
David “20K” Black
On Tue, 4 Jul 2006, Mauricio F. wrote:
noticed the alias “invoke_functional_method”?
hmmm the link between “might be called externally despite being private” and
“functional” is subtle, to say the least;
#invoke_private_method seems much clearer (even if inaccurate) and is nearly
as long if you want to discourage its use.
how bout
invoke_method! # dangerous because invokes even private
??
-a
Hi –
On Tue, 4 Jul 2006, [email protected] wrote:
how bout
invoke_method! # dangerous because invokes even private
I suggested send! long ago, but Matz didn’t like it.
David
On Jul 3, 2006, at 10:59 AM, [email protected] wrote:
I haven’t noticed invoke_functional_method. I admit I’m still unclear
on the (new?) use of the notion of ‘function’ in addition to
‘method’… How do you characterize a functional method, in this
context?
Well, a private method is not suppose to be invoked externally, so
it’s not really a “method call.” That’s my best guess at the
reasoning…
James Edward G. II
Yukihiro M. wrote:
It’s not conjunction with send etc. but with FILE and
LINE. Besides that, I am no longer fond of send and id,
I’d rather like to remove them if it’s possible. Use invoke_method
and object_id respectively instead.
I’d agree, but we need a better system to replace them --not a worse
system. Granted xxx methods aren’t pretty but at least they are
consistant and one knows what to expect. Now we are going to have to
recall, teach, fix broken programs, and generally take into account
even more methods like #invoke_method (what’s that do different from
#send btw?) and #funcall.
I’m looking at this primarily from the point of view of BlankSlate. I
think that application really drives home how all this effects the
system. For example, recently a user tried to use an #eval in a
BasicObject (ie. BlankSlate) and it bombed (of course). So I ask myself
should there be a eval? One could ask this about lots of methods. I
also noticed that the problem is worse when there is a built-in
BasicObject like in Ruby 1.9 b/c then there is no way to get to those
methods at all! So I think maybe this is all the wrong approach. And
the only solution I can think of is separate namespaces for public vs.
private methods.
What is you take on this?
Thanks,
T.
On Jul 3, 2006, at 11:03 AM, [email protected] wrote:
how bout
invoke_method! # dangerous because invokes even private
??
Yeah, I’m with David in that I liked send/send!, so this seems a
natural extension to me.
James Edward G. II
On Tue, Jul 04, 2006 at 01:00:30AM +0900, [email protected] wrote:
hmmm the link between “might be called externally despite being private”
and “functional” is subtle, to say the least; #invoke_private_method seems
much clearer (even if inaccurate) and is nearly as long if you want to
discourage its use.I think it’s inaccurate to the point of really not being usable.
Conceded. #invoke_even_if_private also came to mind but it seems a bit
excessive.
I admit I’m still a fan of send/send! but I guess they’re long gone
I also like it (! never really meant “danger” to me).
Hi –
On Tue, 4 Jul 2006, Mauricio F. wrote:
I admit I’m still a fan of send/send! but I guess they’re long gone
I also like it (! never really meant “danger” to me).
I like it too, and ! always did mean “danger” to me (And to
Matz, I always thought, but maybe I’m out of date.) The “danger” in
this case is the inclusion of methods you normally wouldn’t be able to
call and might not even know about.
David
Hi,
In message “Re: About 1.9 #method feature.”
on Tue, 4 Jul 2006 00:59:21 +0900, [email protected] writes:
|I haven’t noticed invoke_functional_method. I admit I’m still unclear
|on the (new?) use of the notion of ‘function’ in addition to
|‘method’… How do you characterize a functional method, in this
|context?
I refer a method invocation without a receiver specified as
“functional style” because it looks like function calls in other
languages. The name “funcall” and “invoke_functional_method” reflect
that term.
matz.This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs