On 9/16/2010 8:00 PM, J=F6rg W Mittag wrote:
> Walton Hoops wrote:
>> I'm afraid code completion for Ruby is pretty much out.
> Why? Other, much more dynamic languages have had that for more than 30
> years. Why shouldn't that be possible for Ruby?
>
> jwm
>
I suppose it depends on what you mean by code completion.  Since the OP
stated that Netbeans didn't do code completion, I assumed what we were
referring too is actually know that the object in question is of class
A, and here are all the methods one can call on an object of class A.=20
That's likewise what I would call true code completion.

The best Ruby IDEs can ever hope to do however, is what Netbeans +
others do, take their best guess as to what they think MIGHT be stored
in the object 'a' and present you with the methods they THINK are
available.  Of course, it could turn out that 'a' isn't what Netbeans
thought it might be, has methods that Netbeans was unaware of, or
methods have been removed at run-time.

If you think about it it should be pretty clear, in a language with
eval, truly accurate static analysis for code completion can never be
complete, it's always a best-guess situation.  Even if we were somehow
magically able to see what methods are defined on an object at a given
place in code, we still couldn't manage complete code completion,
because it's not unheard of for methods to be defined when called for
the first time via the magic of method_missing.

So I guess the point I'm trying to make is that what people coming from
other languages like Java tend to think of as code completion, that is,
I hit the '.' key and suddenly all the options that are available appear
in a nice little menu on my screen, isn't possible.  Guessing is
possible, but in my experience, it's easier and more reliable to read
the docs or examine the object in IRB, than to wade through all of
Netbeans' or RubyMine's guesses.