In article <courier.4249F4B9.0000089A / mars.sisgroup.com.au>, Adelle Hartley
wrote:
>It has been said that features like "intellisense" or "autocomplete" are
>difficult to implement for dynamic languages such as Ruby.
>
>I'd be happy with an IDE that let me choose a .rb file per project, let's
>call it "environment.rb" which would usually be a list of "require"
>statements which would establish a run-time state that would be a fair
>approximation of what classes and methods would be available to 90% of my
>application.
>
>I mean, sure, dynamic languages let us add/remove classes variable and
>methods anytime we like, but during the first moments of my application's
>startup I usually set up 90% of the classes that I will need during the
>remainder of the program's execution.

How do you know which class is associated with a particular variable?

	a = somemethod(1, 2, 3)
	a.<TAB> # what methods are available? We have an approximation of
		# the classes/methods in the system, but no idea what
		# `a' corresponds to.
		#
		# You could use "Foo.new is an 'atomic' type constraint,
		# everything else bubbles up from these kind of constraints",
		# but how reliable would that be?

.... although if you had decent unit test coverage, you could use the unit
tests to guess what variables probably correspond to.

"When we ran the unit tests, `a' was an instance of Foo, so assume for code
completion that `a' is a Foo."

+ do some simple inference from e.g. Foo.new.

-- 
Drunk, ignore if nonsensical.