Francis Hwang
10/27/2004 4:15:00 AM
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.)
>