On Wed, 26 Jan 2005, itsme213 wrote:

> Smalltalk's refactoring browser is image-based. The environment is
> working on the end-result of all dynamic stuff (with the effective
> source representation of that end-result). If you have dynamically
> added a method to a class, that method shows up in the browser (I
> think!). Wouldn't it be far more difficult to implement such a tool
> based solely on the source-code that caused all that dynamic stuff to
> happen in the first place. Is image-based tooling a mismatch for Ruby?
> Hmmm.

Depends what kind of Ruby one writes. I have written a lib that includes a
spec of the X11 display protocol, and is less than 100k, yet defines over
400 classes, most of which are anonymous, and most defined methods are
eval'ed from strings built at load time.

Well, needless to say that any class browser chokes to death on that kind
of code.

I think that thoroughly applying DRY/OAOO much lessens the need for a
class browser (refactoring or not), but that's still a vague opinion, as I
don't really have projects that would benefit from it, so I never had 
the occasion to try those techniques.

Eg, the project I spend the most time on is written in a combination of
mainly four languages (Ruby, C++, PureData, Tcl).

_____________________________________________________________________
Mathieu Bouchard -=- MontrñÂl QC Canada -=- http://artengine.ca/matju