Trans
7/8/2006 5:04:00 AM
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'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.