From: Mauricio Fernandez <mfp@...>
Date: 2008-02-19T19:24:45+09:00
Subject: Re: [ANN] FastRI 0.3.1: faster, Leopard compatibility, etc.

On Tue, Feb 19, 2008 at 01:45:09AM +0900, James Britt wrote:
> >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?
> 
> I'm curious if drbrain is planning any changes to rdoc that would change 
> how ri might behave differently.
> 
> One of my complaints with the current ri/rdoc situation is how elective 
> module mixins get pushed into various class docs by default.  For 
> example, looking up String, I see that strings have a to_yaml method. 
> Except, of course, they don't unless you explicitly include the YAML module.
> 
> ri and rdoc are brain-dead with regard to dynamic class composition.
> 
> fri has the exact same behavior (since it's using the same broken 
> datastore as ri)
> 
> It gets worse as more gems are installed if they do any base class 
> alterations.  (f)ri tells me that strings have a "_expand_ch" method. I 
> have no idea where that even comes from.

FastRI gets the documentation from ri's datastore(s) but does one thing
differently: it doesn't blindly merge the information from different sources,
it also remembers which gem a method/class came from. This information is not
exposed yet, however, but you can expect FastRI to allow you to restrict
lookups to a given set of gems (and maybe tell you where a method came from for
unscoped searches) eventually.

-- 
Mauricio Fernandez  -   http://eigenclass.org