From: James Gray <james@...>
Date: 2008-02-19T22:55:43+09:00
Subject: Re: [ANN] FastRI 0.3.1: faster, Leopard compatibility, etc.

On Feb 19, 2008, at 4:12 AM, Mauricio Fernandez wrote:

> On Mon, Feb 18, 2008 at 11:17:52PM +0900, James Gray wrote:
>> On Feb 18, 2008, at 5:53 AM, Mauricio Fernandez wrote:
>>> $ ri -T collect_file
>>> More than one method matched your request. You can refine
>>> your search by asking for information on one of:
>>>
>>>   Test::Unit::Collector::Dir#collect_file,
>>>   Test::Unit::Collector::Dir#collect_file,
>>>   Test::Unit::Collector::Dir#collect_file,
>>>   Test::Unit::Collector::Dir#collect_file,
>>>   Test::Unit::Collector::Dir#collect_file
>>>
>>> Unfortunately, ri is so slow and buggy that many (me included)  
>>> find it
>>> unusable. FastRI is just an usable ri with some extra features   
>>> (working
>>> RubyGems support, full-text search, configurable lookup order,   
>>> better
>>> search strategies, etc.).
>>
>> Amen.
>>
>> We had so many bug reports on TextMate's documentation command when  
>> we
>> used ri.  We later switched to qri (part of FastRI) and added some
>> documentation about how to install it.  Our bug reports are
>> practically gone now.  When we do see one, we point them at the
>> install documentation and it solves their problem.
>>
>> I really don't understand why we don't toss RI in the standard  
>> library
>> and replace it with the FastRI code.  It's RI with more features,  
>> it's
>> faster, oh and it works.  What's the downside exactly?
>
> It goes against the current trend of moving stuff out of the  
> standard library and distributing it as RubyGems packages.

I understand why we should do that when a standard library really  
isn't needed in all cases.  However, it doesn't get much more  
important than documentation and what ships with Ruby is just broken.   
I think it would be so much better to just replace it at this point.

In the 1.9 release we replaced CSV with FasterCSV.  This seems about a  
thousand times more important than that.

> Admittedly, the statu quo is not satisfactory: Ruby ships with a  
> broken tool
> that gives a very poor image and detracts new users from looking for  
> something
> better (one naturally expects the standard library to contain best- 
> of-breed
> components). There are three solutions to this:
> (1) keep RI in the standard library and fix it. This amounts to  
> rewriting
>    FastRI, though, and duplicating efforts this way would be stupid.
> (2) remove the "ri" tool from the stdlib (*not* the RDoc/RI library  
> parts, since
>    existing programs, including FastRI, depend on it) and distribute  
> it as a
>    gem, or dump it altogether and let people install FastRI instead
> (3) replace ri with FastRI's qri in the standard distribution.
>
> (1) is silly. I favor (2) because it's the one that demands the  
> least effort
> from me ;) and it's consistent with matz's intention to make the  
> standard
> distribution leaner.

I favor (3), but I guess that really only works if you support it.  :)

James Edward Gray II