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, transfire@gmail.com 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.
can we also have
__METHOD__ # just the name
for symmetry?
-a
On Tue, 4 Jul 2006, Yukihiro Matsumoto wrote:
Hi,
In message "Re: About 1.9 #__method__ feature." > on Mon, 3 Jul 2006 23:33:54 +0900, transfire@gmail.com 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.
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
Hi --
On Tue, 4 Jul 2006, Yukihiro Matsumoto wrote:
Hi,
In message "Re: About 1.9 #__method__ feature." > on Mon, 3 Jul 2006 23:33:54 +0900, transfire@gmail.com 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.
Speaking of send: is the 'funcall' name definite? Are you still
interested in hearing arguments against it? 
David
--
"To fully realize the potential of Rails, it's crucial that you take
the time to fully understand Ruby--and with "Ruby for Rails" David
has provided just what you need to help you achieve that goal."
-- DAVID HEINEMEIER HANSSON, in the foreword to RUBY FOR RAILS.
Complete foreword & sample chapters at http://www.manning.com/black\!
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 7/3/06, Yukihiro Matsumoto <matz@ruby-lang.org> 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.
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca
Yukihiro Matsumoto wrote:
Hi,
>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.
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.
In message "Re: About 1.9 #__method__ feature." > on Mon, 3 Jul 2006 23:33:54 +0900, transfire@gmail.com writes:
Yukihiro Matsumoto wrote:
Hi,
>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'm with you, ditch __send__ and __id__. But why not ditch all the
__'s if they are ugly, including __FILE__, __LINE__? What's wrong with
globals: $LINE, $FILE, $METHOD, or better yet $line, $file, $method?
After all we use globals for lots of *current* things like $' and
$stdin, and $FILENAME.
I'd rather like to remove them if it's possible. Use invoke_method
and object_id respectively instead.
Please consider #object_send. The "object_" prefix indicates that it
something best left alone -ie. this is defined by object/kernel and you
override it only at your own peril! I think this is a great mnemonic
device. I also think #class ought to become #object_class (which would
also free us from having to use the receiver: self.class) That would
give us:
object_id
object_class
object_send
Then for the all methods that bypass access resitrictions:
instance_send
instance_eval
instance_exec
instance_variable_get
instance_variable_set
instance_variables
That way it's consistant, intuitive, easy to use and easy to learn.
The only exceptions is #instance_of? But that's moot if you ask me b/c
it's safer to ask the class anyway. So preferably we would have
Class#class_of?(obj) plus a word alias for Module#=== like
Module#ancestor_of?(obj).
T.
In message "Re: About 1.9 #__method__ feature." > on Mon, 3 Jul 2006 23:33:54 +0900, transfire@gmail.com writes:
Hi,
In message "Re: About 1.9 #__method__ feature." on Tue, 4 Jul 2006 00:14:13 +0900, ara.t.howard@noaa.gov 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, dblack@wobblini.net 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.
Hi,
In message "Re: About 1.9 #__method__ feature." on Tue, 4 Jul 2006 01:10:40 +0900, transfire@gmail.com writes:
What is you take on this?
I am sorry but I am not sure what you're asking here.
I have considered separating public and private method name spaces
several times, but always failed to make it well designed.
matz.
Hi,
In message "Re: About 1.9 #__method__ feature." on Tue, 4 Jul 2006 00:37:31 +0900, "Austin Ziegler" <halostatue@gmail.com> writes:
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).
I am not yet sure how much preferable adding 1.9 methods to the stable
version. Since it is mere addition, it should not cause much
problems, but increasing number of methods may be considered as being
"unstable" for the stable version. Any idea?
matz.
transfire@gmail.com wrote:
object_id
object_class
object_sendThen for the all methods that bypass access resitrictions:
instance_send
instance_eval
instance_exec
instance_variable_get
instance_variable_set
instance_variables
I agree with that proposal, and I think it underlines a fundamental dichotomy that I've been seeing in the discussion. Basically some people approach this as users; they want the names to reflect how the methods are used. And some people approach it as language designers; they want the names to reflect what is actually going on inside the interpreter. I think the first approach is the correct one; an interface is not supposed to reveal all the ugly or complicated or subtle details of the architecture within.
Daniel
+1
Sean
On 7/8/06, transfire@gmail.com <transfire@gmail.com> wrote:
Please consider #object_send. The "object_" prefix indicates that it
something best left alone -ie. this is defined by object/kernel and you
override it only at your own peril! I think this is a great mnemonic
device. I also think #class ought to become #object_class (which would
also free us from having to use the receiver: self.class) That would
give us:object_id
object_class
object_sendThen for the all methods that bypass access resitrictions:
instance_send
instance_eval
instance_exec
instance_variable_get
instance_variable_set
instance_variablesThat way it's consistant, intuitive, easy to use and easy to learn.
why not simply
send
send!
eval
eval!
exec
exec!
etc.
i like the idea - but those are long names! 
-a
On Sat, 8 Jul 2006 transfire@gmail.com wrote:
object_id
object_class
object_sendThen for the all methods that bypass access resitrictions:
instance_send
instance_eval
instance_exec
instance_variable_get
instance_variable_set
instance_variablesThat way it's consistant, intuitive, easy to use and easy to learn.
The only exceptions is #instance_of? But that's moot if you ask me b/c
it's safer to ask the class anyway. So preferably we would have
Class#class_of?(obj) plus a word alias for Module#=== like
Module#ancestor_of?(obj).
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
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:
On Tue, 4 Jul 2006, Yukihiro Matsumoto wrote:
#
# an array of objects representing call record
#
where = __where__
#
# the first record is the call we're in
#
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
#
# but this one reaches up like binding_of_caller #
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
#
# and even further!
#
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
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
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.
On Tue, Jul 04, 2006 at 12:39:12AM +0900, Yukihiro Matsumoto wrote:
Hi,
In message "Re: About 1.9 #__method__ feature." > on Tue, 4 Jul 2006 00:31:03 +0900, dblack@wobblini.net 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"?
--
Mauricio Fernandez - http://eigenclass.org - singular Ruby
Hi --
Hi,
>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 Matsumoto wrote:
In message "Re: About 1.9 #__method__ feature." > on Tue, 4 Jul 2006 00:31:03 +0900, dblack@wobblini.net writes:
--
"To fully realize the potential of Rails, it's crucial that you take
the time to fully understand Ruby--and with "Ruby for Rails" David
has provided just what you need to help you achieve that goal."
-- DAVID HEINEMEIER HANSSON, in the foreword to RUBY FOR RAILS.
Complete foreword & sample chapters at http://www.manning.com/black\!
Yukihiro Matsumoto wrote:
Hi,
>What is you take on this?
I am sorry but I am not sure what you're asking here.
No problem. I will try to paint better picture. I have variant of
OpenStruct called OpenObject:
class OpenObject < BasicObject #(this is my BasicObject like
BlankSlate)
...
Using BasicObject as parent removes (almost) all kernel methods which
ensures no name clashes when using the OpenObject. Problem is sometimes
those removed methods are needed. So the important ones are available
by shadow methods, like __send__ even though #send is removed. Problem
is A) how many and which kernel methods should be shadowed; all of
them? and worse B) it means users have to be aware when a subclass of
BasicObject might be used and call the LCD, ie. shadow methods instead
of regular methods.
I came up with one idea that fixes A. using #__self__, eg.
o = OpenObject.new
o.class #=> nil
o.__self__.class #=> OpenObject
But it does not solve worse problem of B. Separate public vs. private
methods would solve that though since kernel methods are generally
private.
I have considered separating public and private method name spaces
several times, but always failed to make it well designed.
What were the sticking points? I spent some time considering this and
arrived at a conception of layers, almost like subclassing, eg
MyClass:Public < MyClass:Private.
T.
In message "Re: About 1.9 #__method__ feature." > on Tue, 4 Jul 2006 01:10:40 +0900, transfire@gmail.com writes:
Yukihiro Matsumoto wrote:
>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.
I was under the impression that __FILE__ was in capital letters because it was a constant (or rather, pseudo-constant). If __method__ is really a method that can be called with self.__method__ then by all means it should be lowercase. But if it's a (pseudo)constant then it should keep the nomenclature of constants, i.e. uppercase letters.
Daniel
Doesn't this depend on how it's added? What if we stole a page from python's book?
file future.rb:
module Kernel
alias invoke_method __send__
end
require 'future'
obj = SomeClass.new
obj.invoke_method(...)
You could also have an empty future.rb in the stdlib of 1.9. Then people who try to write 1.8 in a 1.9 style could use their scripts under either version (well as far as stuff that could be backported for "getting into the habit" purposes, like invoke_method).
Just a thought.
On Jul 4, 2006, at 1:07 AM, Yukihiro Matsumoto wrote:
I am not yet sure how much preferable adding 1.9 methods to the stable
version. Since it is mere addition, it should not cause much
problems, but increasing number of methods may be considered as being
"unstable" for the stable version. Any idea?matz.