Re: Proposal: runtime-modifying Kernel methods should be keywords

Florian Gross wrote:
> 
> On Jul 13, 8:55 am, Charles Oliver Nutter <[e-mail]>
> 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 <[e-mail]> 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. ;)

No, I used to think Binding.of_caller was a good idea, but I see a 
crucial flaw in it now...you have no idea whether the caller's binding 
is valid or safe to use. In the case of these optimizations we've been 
discussing, there may not even be a caller binding to get...not to 
mention that there's no way to force the caller to start using your 
heap-allocated Binding constructs (frames, scopes) when it regains 
control. Too much danger.

> 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...

That's preferable, because we can scan a given method and know whether 
it will use such variables, preparing whatever structures are needed for 
them. We can also improve performance of a few methods that set them, 
avoiding e.g. creating MatchData inside gsub when it will never be used.

- Charlie

- Charlie