[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Thu, 12 Jun 2003, Scott McKay wrote:

> This functionality has absolutely nothing to do with
> whether or not source code is stored in files, which
> was the point of my second bullet item.  The protocols
> being used here are:
>   - Given a class, generate its subclasses
>   - Given a class, go find its source code
>   - Given a piece of source count, count the lines in it
> This was all supported in the Harlqn Dylan environment,
> with no mucking around with importing and exporting.

I'm not saying you can't do semantic analysis of files, and provide
something close to a Smalltalk environment (in terms of source navigation
and editing) without using the image model.  Eclipse is a good example of
this - it gives you senders/implmentors, package browsing, some
refactorings, all while keeping the file-based Java model underneath.  I
think that's great.

What drives me nuts about Eclipse is that although it provides all that,
it still shows me my source code in the context of a file.  VAJ got
it right - once you have all of those tools, you don't need to expose the
notion of file anymore.  It can be there underneath, but what matters is
the in-memory model/database being built by the environment, and if the
tools are there (particularly progammatically, or you'll have a hard time
replacing grep + co), that's all the user should need.

And of course you have to muck about with importing and exporting - you
probably called it "open" and "save".