From: Yehuda Katz <wycats@...>
Date: 2008-12-06T05:31:27+09:00
Subject: [ruby-core:20389] Re: Leave my open classes alone (was Behavior: autoload calls rb_require()  directly)

Matz,

One possibility is that packages are first-class concepts (in 2.0?)  
and new methods or changes to existing methods could be restricted to  
a package (optionally -- packages could still decide not to protect  
their changes and make them global).

If this is done, it would moot the most common need for selector  
namespaces (libraries that extend core classes for internal convenience)

If packages could be imported into other packages, or the "global"  
package, users could decide, for instance, if they wanted Merb's core  
extensions or Rails'

Does this make sense?

Sent from my iPhone

On Dec 4, 2008, at 2:40 PM, Yukihiro Matsumoto <matz@ruby-lang.org>  
wrote:

> Hi,
>
> In message "Re: [ruby-core:20323] Leave my open classes alone (was  
> Behavior: autoload calls rb_require()  directly)"
>    on Fri, 5 Dec 2008 06:25:08 +0900, Dave Thomas  
> <dave@pragprog.com> writes:
>
> |Every time we do something like this, we add more special cases to  
> the
> |language. Right now, classes are open. We allow people to modify  
> their
> |behavior. That's just Ruby. Take away plus, and you limit my freedom.
> |What's next? Maybe Fixnum.to_s. And then maybe Struct.to_s. And then
> |maybe all internal classes get closed, and no one would be able to
> |create things such as Symbol.to_proc.
>
> Don't get me wrong.  No matter how Charles agreed, I said I wanted to
> separate the namespace, and protect core from "casual" user
> modification, but did not intended to freeze anything.  Actually quite
> opposite.
>
> Another example is mathn library, which replaces core math operation
> in a somewhat useful manner, but introduces serious incompatibility at
> the same time.  If we can separate effect of mathn in a region or
> namespace, we can live happier with controlled monkey patching.
>
> |I'd much rather see change going the other way. I'd like to see a =
> |"cat" calling String.new. I'd like to see fewer special cases.
>
> Interesting.  if a = "cat" calls String.new, it should take an
> (string) argument to initialize the content "cat", then how should the
> original content sting be initialized?
>
>                            matz.
>
>