Matthias Felleisen wrote:
>> On Sep 26, 2007, at 10:04 PM, Anton van Straaten wrote:
>>> However, I wasn't actually arguing for doing that (yet!) Instead, I
>> was saying that generalizing the idea of saving a list of open files
>> would provide for future extensibility in that direction, among
>> others. Since DrScheme is an extensible environment, providing
>> features in a form that can easily be reused by other extensions
>> seems appropriate.
>>> As Robby pointed out, a product is uniquely determined via its main
> module. So a useful tool is one that opens all transitive (file ...)
> dependencies in tabs and/or the module browser.
>> [We did have a notion of a project, unless my memory deceives me. So we
> are not speaking w/o experience.]
My suggestion was definitely not about introducing a project
abstraction, or having a way to transitively open all files associated
with a program. It's almost the opposite, in fact: the idea of the
task-focused approach is that one typically only deals with a subset of
the files in a program at any one time, and it helps if the development
environment lets you focus on that subset and nothing else. However, to
do that effectively, it helps to have ways of identifying those subsets,
saving them, and reactivating them at some later time.
In general, these subsets tend to cross-cut the overall program in
almost arbitrary ways: the connection between the files you're
interested in at any one time may have to do with the dynamic flow of
execution, or with data structures that are shared across modules, etc.
Practically speaking, today at least, there's no way in general for
the environment to predict what files you need for a task you want to
perform. So the task-focused approach lets you identify a set of files
you're interested in, save that somehow, and reuse it when you need it.
On the subject of projects, where I was coming from when I mentioned
recapitulating the history of IDEs is that a common path in IDE
development seems to have been:
1. Simple single-file editor.
2. Support multiple files open simultaneously.
3. Remember the set of open files between invocations.
4. Add a project feature so that you can easily switch between sets of
"known" files.
This thread began with a request for #3. For the same sorts of reasons
that I described above, #3 is a reasonable request, even given
DrScheme's understanding of modules and ability to traverse the module
graph. I was just pointing out that providing #3 in a slightly more
general form makes it quite easy to do:
5. Support task-focused editing.
That's somewhat orthogonal to whether #4 is provided. I tend to agree
that the module browser rather obviates #4, although "projects" are also
often used to manage non-code resources, which the module graph doesn't
help with.
Anton