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

Marcel Molina Jr. wrote:
> On Fri, Jul 13, 2007 at 03:02:06PM +0900, Charles Oliver Nutter wrote:
>> 2. Because many of these methods manipulate normally-inaccessible 
>> runtime state, it is not possible to implement them in Ruby code. 
>> Therefore, even if someone wanted to override them (the primary reason 
>> for them to be methods) they could not duplicate their behavior in the 
>> overridden version. Overriding only destroys their utility.
> 
> I certainly have little influence in this matter, and your appeal is really
> targeted at only a handful of people (Matz, Evan, John, etc) but though I
> acknowledge that having that functionality implemented as methods makes
> little sense especially since all the state it operates on is hidden away in
> the internals, *my* interests and priorities would respond to that problem by
> wanting to consider how those internals my instead be *exposed*. In some
> cases that might not really be straight forward or make sense, and it flies
> in the face of all your desired optimizations but I just wanted to provide a
> perspective from someone with different priorities than yours.

Even this fits well into the proposal. If there were instead keywords to 
open up such aspects of the system, the same optimizations could be 
performed. Basically, what I'm looking for is an acceptable modification 
to a few key features that would allow future implementers to accurately 
calculate up-front characteristics of a given method, rather than having 
to treat all methods as black boxes. The benefits would be quite high.

> In almost all cases I would want Ruby to be more open at the cost of
> performance.

In almost all cases, I would agree with you. But the only practical 
reason these methods are not keywords is so that you can use them in 
your own method names. You can't hook them, reimplement them, or emulate 
them in user code with current Ruby. Being able to define your own 
"local_variables" method, for example, seems a rather weak reason to 
cripple ahead-of-time code analysis.

> Though I'm not against what you are proposing. Given the current state of
> affairs, it makes sense to make all those things keywords. I'd just rather,
> idealistically, move in the other direction.

If that's more likely and less impact, I will surely agree with you. If 
not, perhaps we'll both still agree on how to proceed.

- Charlie