From: Francis Hwang <sera@...>
Date: 2004-10-27T13:15:24+09:00
Subject: Re: Auto-completion editor/IDE

Patrick put it pretty well when we were hanging out talkin' Ruby night: 
He said "The same features that make Ruby fun for humans to write makes 
it hard for computers to read." All the extra typing you do for, say, 
Java, makes it a lot easier to write things like auto-completion, 
refactoring tools, etc.

At any rate, one thing I'd look at is 'irb/completion', which does 
auto-completion in irb. I haven't looked at the internals, but I use it 
all the time and it would be probably be a good place to start.

F.

On Oct 26, 2004, at 9:24 PM, Tim Sutherland wrote:

> In article <1098834541.819479.278620@f14g2000cwb.googlegroups.com>, 
> Eli Tucker
> wrote:
>> Does anyone have any info on an IDE or editor that supports
>> auto-completion for Ruby?
>>
>> So far I've been using Scite which came with the One-Click Windows 
>> Ruby
>> installer, but have not figured out how to turn on auto-completion (or
>> to be more specific, how to create the needed api file).
>>
>> I just downloaded RDE, but the auto-completion seems half baked.  For
>> example, if I type the following:
>>
>> a = [4,2,3]
>> b = a.
>>
>> a pop-up is shown just like you would expect where I can select a
>> method of Array.  But then if I continue along to here:
>>
>> a = [4,2,3]
>> b = a.sort
>> b.
>>
>> ... no pop-up is shown -- it doesn't know that b is an Array.
>>
>> Perhaps there isn't yet an IDE or editor for Ruby with auto-completion
>> features like those seen in Microsoft Visual Studio, Jet Brains IDEA,
>> or Eclipse?  If not, I would be interested in hearing what other
>> developers are using to create ruby code.
>
> I don't think there is one. It's a difficult problem because Ruby is 
> such a
> dynamic language (e.g. `method_missing'). (In fact, it's impossible to 
> do a
> perfect job automatically.)
>
> I've been thinking a little about what would be needed to achieve at 
> least
> an "approximate" auto-completion.
>
> Rdoc (inline documentation tool) gives us a list of classes and the 
> methods they
> implement. It allows for documenting methods/classes that it fails to 
> find
> automatically. I believe that any auto-completion system should use 
> rdoc
> data - if a method has been nicely documented you get auto-completion, 
> and
> otherwise you don't.
>
> The missing component is the "type" a method returns. e.g. in your 
> example,
> that Array#sort returns an Array.
>
> It's true that the methods an object responds to generally corresponds 
> to
> the instance methods of its class. So ignore the cases when this isn't 
> true.
>
> Also, methods can be redefined at runtime, e.g. Array#sort could be 
> modified
> to return a `MagicArray' having different methods. At least in these 
> cases
> the methods supported by the new return type should be approximately 
> the
> same as the old. (To preserve duck typing.) Ignore this problem.
>
> Then add a tag to the rdoc markup for specifying return type(s) (as 
> names of
> classes). Methods defined in C extensions would need these to be 
> specified
> manually.
>
> We can then do type inference on methods defined in Ruby to determine 
> the
> likely return types. We'll need some tricks for when many different 
> types
> can be returned, e.g. "def identity(x); x; end". Incorrect/incomplete
> results can be fixed via the rdoc tag.
>
> A big problem with this type guessing system is that when it gets a 
> method
> type wrong, the error will "bubble up" through the rest of the code, 
> i.e.
> any other method whose return value is from that method can be wrong 
> too.
> (Whereas if rdoc gets the methods of a class wrong, the error is 
> localised.)
>
> There are also some problems when the possible return "types" don't
> correspond to any documented classes. e.g.
>   def method
>     class << Object.new
>       def hello
>         puts('hello'
>       end
>     end
>   end
>
> Maybe we can live with these being wrong.
>
>
> In a few weeks I may have time to experiment with these ideas. Whether
> they're good probably depends whether confusion resulting from 
> incorrect
> inference causes more problems than it solves. (i.e. cure worse than 
> the
> complaint.)
>