From: Michael Letterle <michael.letterle@...>
Date: 2008-12-05T06:58:33+09:00
Subject: [ruby-core:20326] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

------=_Part_11625_31982573.1228428269438
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Being able to redefine something as basic as FixNum#+ is something that I
think makes Ruby... well Ruby.  If someone needs to lock it down, can't they
just do something like "require 'strict-fixnum'"?

Sometimes we really want 11 + 3 to = 2... sometimes we want it to = 14.

On Thu, Dec 4, 2008 at 4:41 PM, Charles Oliver Nutter <
charles.nutter@sun.com> wrote:

> Dave Thomas wrote:
>
>> Please, no.
>>
>> 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.
>>
>> 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.
>>
>> If require is broken, then fix it. But don't stop me replacing it if I
>> want. And if I replace it incorrectly (making it not thread safe, for
>> instance) that then becomes my fault.
>>
>> Ruby is about choice. If I wanted a language implementor to tell me what I
>> can change and what I can't change, I'd use Python or Java.
>>
>
> I can appreciate the "choice is good" argument, but I think the Ruby world
> needs a little less dogmatism about "choice" and "freedom" and "beauty".
> There's practical concerns here, concerns about API stability,
> thread-safety, performance, memory efficiency. Too many of those concerns
> are sacrificed on the altar of "choice" or "freedom".
>
> In the case of core classes, we're not talking about closing them down
> completely; we're talking about guaranteeing to all developers and users
> that some minimum set of methods will do what you expect them to do, now and
> forever. We're guaranteeing that 1 + 1 will continue to == 2. And it's not
> the case where *you* want to override a core method that's the
> problem...it's the case where someone else overrides it--potentially by
> mistake--and you don't find out about it until later.
>
> Ruby needs to grow up as a language by allowing people who want guarantees
> to get guarantees. And there's a lot of people who want some minimal, basic
> guarantees about core classes.
>
> - Charlie
>
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

------=_Part_11625_31982573.1228428269438
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Being able to redefine something as basic as FixNum#+ is something that I think makes Ruby... well Ruby.&nbsp; If someone needs to lock it down, can&#39;t they just do something like &quot;require &#39;strict-fixnum&#39;&quot;?<br>
<br>Sometimes we really want 11 + 3 to = 2... sometimes we want it to = 14.&nbsp; <br><br><div class="gmail_quote">On Thu, Dec 4, 2008 at 4:41 PM, Charles Oliver Nutter <span dir="ltr">&lt;<a href="mailto:charles.nutter@sun.com">charles.nutter@sun.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Dave Thomas wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Please, no.<br>
<br>
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&#39;s just Ruby. Take away plus, and you limit my freedom. What&#39;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.<br>

<br>
I&#39;d much rather see change going the other way. I&#39;d like to see a = &quot;cat&quot; calling String.new. I&#39;d like to see fewer special cases.<br>
<br>
If require is broken, then fix it. But don&#39;t stop me replacing it if I want. And if I replace it incorrectly (making it not thread safe, for instance) that then becomes my fault.<br>
<br>
Ruby is about choice. If I wanted a language implementor to tell me what I can change and what I can&#39;t change, I&#39;d use Python or Java.<br>
</blockquote>
<br></div>
I can appreciate the &quot;choice is good&quot; argument, but I think the Ruby world needs a little less dogmatism about &quot;choice&quot; and &quot;freedom&quot; and &quot;beauty&quot;. There&#39;s practical concerns here, concerns about API stability, thread-safety, performance, memory efficiency. Too many of those concerns are sacrificed on the altar of &quot;choice&quot; or &quot;freedom&quot;.<br>

<br>
In the case of core classes, we&#39;re not talking about closing them down completely; we&#39;re talking about guaranteeing to all developers and users that some minimum set of methods will do what you expect them to do, now and forever. We&#39;re guaranteeing that 1 + 1 will continue to == 2. And it&#39;s not the case where *you* want to override a core method that&#39;s the problem...it&#39;s the case where someone else overrides it--potentially by mistake--and you don&#39;t find out about it until later.<br>

<br>
Ruby needs to grow up as a language by allowing people who want guarantees to get guarantees. And there&#39;s a lot of people who want some minimal, basic guarantees about core classes.<br>
<br>
- Charlie<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Michael Letterle<br>[Polymath Prokrammer]<br><a href="http://blog.prokrams.com">http://blog.prokrams.com</a><br><br><br>

------=_Part_11625_31982573.1228428269438--