From: timsuth@... (Tim Sutherland)
Date: 2004-10-27T10:24:04+09:00
Subject: Re: Auto-completion editor/IDE

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.)