From: Trans <transfire@...>
Date: 2005-08-29T21:11:22+09:00
Subject: Re: Method behaves differently when called using #send


Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: Method behaves differently when called using #send"
>     on Mon, 29 Aug 2005 06:46:22 +0900, "Trans" <transfire@gmail.com> writes:
>
> |BUT this would BREAK old programs. Many of us have depended on the fact
> |that #send shoots past access controls. Now I'm not saying it's
> |necessarily a bad idea --certianly the ! can be used for more than just
> |in place modifiers, that's fine. So I'll go along if Matz really wants
> |to do this, but it would mean a lot of code fixes.
>
> Right.  But Ruby2 is the only place to make it happen, when we want to
> make an incompatible change.
>
> |The idea is that if we simply allow a string to follow the
> |receiver-dot, eg.
> |
> |  a."meth"
> |
> |Then this way of calling a method falls right in line with what is
> |wanted: a send that does not bypass access --you can't even use it
> |without a receiver, which is fine, b/c in that case #send would be fine
> |to use anyway.
>
> Excuse me, but I don't get it.  a."meth" to invoke private "meth"?
> How can we invoke a method specified by a variable foo?

via interpolation

  a."#{foo}"

> |I think people worry that it will open up the language to all sorts of
> |crazy method names, like:
> |
> |  johnny."run down the street!"
>
> Stringified method names are good way to specify weird looking method
> names, along with :"foo bar baz" syntax, if we really want them (but I
> doubt we need them).  But giving it visibility control semantics is
> obviously overuse.

Stringified method names would have the same visibility controls as
non-stringified. It is #send that does/would not.

But I understand about doubting we need them. I just wish there was a
way to implement some variation in method names for special use cases
like E4X. (ie. a.@meth), Stringified method names was the closest
possiblity I've come across.

Thanks,
T.