From: Florian Gross <florgro@...>
Date: 2007-07-14T00:10:37+09:00
Subject: Re: Proposal: runtime-modifying Kernel methods should be keywords



On Jul 13, 8:55 am, Charles Oliver Nutter <charles.nut...@sun.com>
wrote:
> Yukihiro Matsumoto wrote:
> > Hi,
>
> > In message "Re: Proposal: runtime-modifying Kernel methods should be keywords"
> >     on Fri, 13 Jul 2007 15:42:06 +0900, Charles Oliver Nutter <charles.nut...@sun.com> writes:
>
> > |I'd say anything that fits both of the following criteria qualifies:
> > |
> > |- the feature can't be implemented without knowing how to manipulate
> > |runtime/implementation-specific structures (and having a way to
> > |manipulate those structures)
> > |- the feature can't be wrapped in another method and maintain the same
> > |behavior as if it were called in the original context
> > |
> > |All those listed so far fit these criteria.
>
> > String#gsub ?
>
> gsub needs access to internal structures (namely, the in-memory
> representation of a String) but it can successfully be wrapped with
> another method. I think both criteria must be met, since being able to
> wrap a method means it's not doing anything weird with the caller's
> logical binding/frame/scope.

A bit of addendum: In MRI it sets $~ which is implemented as a special
local variable.

That means that you can not override it. You won't be able to set $~
in the context your method was called in. I think Regexp.last_match
just returns $~ from the caller's binding as well.

I guess this is another case for putting Binding.of_caller into the
language. ;)

Not sure if gsub should really be put into the same category as eval,
though. You could always have $~ as a special construct instead of
storing it in a hidden local variable, I think...