RE: LFM + LFSP = LFE?

[Scott McKay <address@hidden>]

At 10:58 AM -0700 6/12/03, Avi Bryant wrote:
>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.

So that's a bug in Eclipse, right?  What the Dylan
environment (which I'll refer to as FD) does is show
you just the single source definition in its browsers
and the debugger.  You can edit the code right in
the browser if you want, or you can click on an
"edit file" button and get to a full-sized editor
to edit the "home" source file for the definition.
It's entirely up to you.

What the Smalltalk model loses is the organizational
intent of the original author of the code, which I
think is very important and is not well captured by
anything other than source files, or something very
much like source files.  (Sure, you might stick source
file-oid objects in a database, but the reason you
would is to capture that intent, and then you've just
source files again.)

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

You never need to do an "open" in FD.  You can always
just directly edit a definition.  You do need to do a
save, but I think that's right and proper even in a
definition-based editing environment.  So, as I said,
you don't need to muck about importing and exporting.