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

TRANS wrote:
> On 7/13/07, John Lam <[e-mail]> wrote:
>> > 3. These methods are exactly the ones that complicate optimizing 
>> Ruby in
>> > all implementations, including Ruby 1.9, Rubinius, JRuby, Ruby.NET, and
>> > others. They confound a compiler's efforts to optimize calls by always
>> > leaving open questions about the behavior of a method. Will it need
>> > access to a heap-allocated scope? Will it save off a binding or the
>> > current call frame? No way to know for sure, since they're methods.
>>
>> +1
>>
>> We have a design (not implemented yet) to throw on an attempt to alias
>> Kernel#eval by default. We would enable aliasing eval with a command
>> line switch along the lines of /MakeItRunSlower :) We have a number of
>> optimizations for non-local control flow that take advantage of using
>> static analysis of a block/proc body. These optimizations simply
>> cannot work in cases where eval appears within the block/proc. If
>> folks could alias eval then we can't do any of the optimizations at
>> all, and that is clearly a bad thing.
> 
> I think 'eval' is a clear choice for keyword. But I'm curious, how
> does that effect Binding#eval?

The tricky part of eval is the implicit binding. If eval always required 
a binding it would not be a problem. In the case of Binding#eval, we're 
providing an explicit binding, so it's not a concern (but the keyword vs 
method conflict is still there...perhaps Binding#eval_under, or 
eliminate it in favor of plain old eval ..., binding).

> As for the others, I don't think the criteria makes sense exactly.
> It's not that one would want to re-implement 'local_variables', for
> example, but rather just reuse the name for something else. Is that
> dangerous? Well, that's Ruby. There are lots of meta-methods that one
> would like to think are always there and always operating as one would
> expect, but you can't. We've had a number of discussions on ruby-talk
> about externalizing such calls in order to avoid overrides. Keywords
> are just another attempt at that.

Is reusing the name that popular that it warrants cluttering the method 
space with methods that aren't methods? Do people really want to 
override local_variables?

We're also not talking about dozens of methods, we're talking about a 
handful of especially invasive ones.

> Just a couple of quick points about particular methods:
>  - I hope block_given? ultimately goes away!

In favor of?

>  - I wish public/private/protected could just be a matter of
>    documentation and leave us too, but I realize that's not
>    likely, so personally I'd rather do like Java:
>      private def x()
>      public def x()
>      protected def x()

public/private/protected are very weird, in that they modify a hidden 
variable in the current scope...a variable that affects future 
operations like defining methods. Making them explicit would be nice, 
but it's not likely to happen. Only allowing the form that takes a 
symbol would eliminate the need to turn them into keywords, but that 
also is unlikely to happen. As long as they have implicit control over 
hidden state (like visibility) they should be keywords.

>  - What about module_function as keyword? (another one I don't like)

module_function is ok because it only uses a symbol form rather than any 
implicit state. It can be wrapped and have the same behavior.

>  - You mention 'binding'. However I prefer my alias 'here'.
>    How would I alias a keyword?

You wouldn't.

- Charlie