From: transfire@...
Date: 2006-07-08T14:04:15+09:00
Subject: Re: About 1.9 #__method__ feature.


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.