From: "David A. Black" <dblack@...>
Date: 2005-05-07T21:46:33+09:00
Subject: RCRs that can be implemented in Ruby (was: Re: Prove me Wrong! Re: RCR 303: nil should accept missing methods)

Hi --

On Sat, 7 May 2005, Ryan Davis wrote:

>
> On May 5, 2005, at 8:39 PM, John Carter wrote:
>
>> If I prove wrong, I will gladly retract my RCR and apologise.
>
> The burden of proof (that this is needed) must sit on you, not on us (that 
> this is not needed).
>
> Either way, I still agree with Eric, there is no reason for this to be an RCR 
> since the whole thing is 5 simple lines of ruby that any user can selectively 
> use as they see fit. If someone wants to use it, they require a very small 
> file. If they don't want to use it, they don't do anything special.

I'm a little puzzled by this (the idea that changes that can be
implemented in Ruby should not be RCRs), which I hadn't heard before
Eric's post, but which seems to be taking Seattle by storm :-)

I don't think implementability-in-Ruby correlates with RCR
appropriateness at all.  There are lots of accepted RCRs that can be
implemented in Ruby, and since the RCR process flows into Matz's work
on the language -- and much of what Matz does can be implemented in
Ruby -- it seems like an artificial barrier.

Also, there are serious pitfalls to falling back on the solution of
just changing core behavior one program or library at a time.  We've
heard from several people, for example, who would not be happy if nil
started eating messages, so presumably if they used a library that
made that change to nil, they wouldn't like it.

This situation may change if there are selector namespaces or
something along those lines in Ruby 2.0, but for the moment I would
say that the RCR process is for all proposed changes to Ruby,
including those that can be implemented in Ruby.


David

-- 
David A. Black
dblack@wobblini.net