[darcs-users] Eclipse integration, refactoring, and combinatorial explosion?

[Marnix Klooster]

Hi all,

Here are some questions that are definitely for post-1.0, but I'd like to
put them down in writing, just to make sure it won't get lost :-)

I think the two strongest points of darcs are:
 * Works in terms of patches and collections thereof; this is a very
   natural way of thinking about software that is developed by
   multiple parties (or even multiple colleagues in one team).
 * Develops in a direction where patches capture the *human
   intention* of a change, instead of just the textual diff.

(By the way, do you agree with this?)

Especially the latter point seems to relate strongly to the refactoring
feature of IDEs like Eclipse (http://www.eclipse.org) and IntelliJ IDEA
(http://www.intellij.com/idea/).  Because in a refactoring, you express your
intention: "Rename class com.mklooster.vehicles.Automobile to
com.mklooster.interfaces.ICar throughout the entire tree".  Such a new patch
type would fit ideally within the darcs philosophy.

So it would be nice if darcs had an Eclipse integration, and if somebody
implementing a new refactoring also could write all code necessary for the
corresponding darcs patch type.

However, this leaves us with three issues:
 1. Technical: how can we 'plug in' new refactoring types into darcs?
 2. Semantical: which code needs to be written for a new patch type?
 3. Practical: how to avoid the combinatorial explosion of commuting
               two patches of two arbitrary types?

I'm not so interested in point 1 right now.  (Personally I think a
Java/Ruby/Python implementation is easier to plug-in to than a Haskell/C/C++
implementation.)

For points 2 and 3, so if darcs really should be extensible, we to try and
find a way to describe a patch type on its own, without any relationship to
other specific patch types.  So it should be possible to define (and code)
e.g. the hunk patch type, the file creation type, and the directory removal
type, as separate 'modules'.  (It is clear that the current code is not
extensible in this sense.)  That separation seems essential to me.

So my questions are: Do you agree that such a modularity is useful or even
essential?  And if you do, how could we achieve it?

(I have a rough idea, I'll try to write that up for a separate post if there
is interest.)

Groetjes,
 <><
Marnix
--
Marnix Klooster
mklooster at baan.nl