[ruby-core:20382] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

I see my simple little question has ruffled feathers in the hen house  
again!

One aspect I'd feel remiss if I didn't mention was the extend to Ruby  
is already not dynamic. Trans brings up a few below, and I guess I'm  
hearing that 1.9 allows you to change != independent of ==?

Dave brought up the idea that a string literal '"cat"' would boil down  
to an invocation of String.new. In Rubinius, '{ 1 => 2 }' is literally  
shorthand for 'Hash[1,2]'.

My point is that there is set of essentially static features already,  
and so the question is how did they become static and should they  
remain static.

I'd imagine that are static in MRI for performance and simplicity, a  
decision if not made at least approved by Matz. So now we've reached a  
crossroads in the ruby community, where Matz has begun to reevaluate  
which of those static features should be static or not.

The point of my initial question was "is autoload calling rb_require()  
a designed static feature or an accidental static feature?" Matz  
answered it, I think, in a round about way that it's an accidental  
static feature.

So, I think this is a very healthy discussion, because it emphasizes  
one of my favorite features of the ruby community, the ability to  
evolve and move forward. But I think that the final word on a lot of  
these questions lives with Matz. A programming language is all about  
managing expectations and assumptions, and to be consistent, I believe  
that Matz has to hand down decisions on things like this.

  - Evan Phoenix

On Dec 5, 2008, at 3:24 AM, Trans wrote:

>
>
> On Dec 5, 1:36 am, "Bill Kelly" <[e-mail]> wrote:
>> From: "Jeremy McAnally" <[e-mail]>
>>
>>
>>
>>> Soooo basically you're advocating a Python-like object tree, which  
>>> is
>>> the single trait about Python's language features that makes me burn
>>> with rage.
>>
>> I think, rather, that Trans was wanting Ruby to be just as open as it
>> currently is,
>
> Yes. And hopefully even more open. I've written code were I wanted to
> redefine ||, &&, !, etc, within special contexts.
>
>> but he was looking for a way to quickly detect whether
>> any crucial class methods have been overridden, that could be used
>> behind the scenes to make decisions about optimization.
>
> Precisely. My thinking-out-load was that the isolation of core static
> code into "Kernels" made a useful delineation for easily determining
> optimizations:
>
>  optimize_methods = Fixnum::Kernel.instance_methods(false) -
> Fixnum.instance_methods(false)
>
> And overrides more elegantly written:
>
>  class Fixnum
>    def +(a,b)
>      puts "adding"
>      super
>    end
>  end
>
> T.
>