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

[Marnix Klooster]

Hi David,

Thanks for taking the time for your detailed reply.

David Roundy wrote:
> On Wed, Dec 10, 2003 at 08:10:25PM +0100, Marnix Klooster wrote:
> > I think the two strongest points of darcs are:
[snip]
> > (By the way, do you agree with this?)
> 
> Yeah, although darcs' simplicity is also pretty nice, with each developer
> naturally having his or her own branch.  The symmetry between every
> repository is definitely a good thing.

Agreed!
 
> > 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.
> 
> This sound very similar to the existing replace patch type...

As Kevin already explained, it is not so simple.  To do the above
refactoring, you have to:
 - change the uses of both com.mklooster.vehicles.Automobile and
   Automobile, in the latter case not all uses (e.g., not
   those referring to carwash.util.Automobile);
 - rename the file Automobile.java to ICar.java, and move it
   to a different directory;
 - change/add related import statements.
So this really is language-dependent, and not simple search-and-replace.

> There is also the question of *should* we "plug in" new patch types.  I
> think the answer is most likely no.  A repository is only as consistent as
> its patch types and their commutations are well defined.  Allowing
> "plugins" would open up whole new avenues for corruption, since each patch
> type might be defined differently by different plugins.
> 
> In my opinion, if a "plugin" patch type were created, the definition of
the
> patch type would have to be stored within the patch itself,
[and later:]
> Modularity in terms of allowing people to write plugins for
> their own patch types only makes sense to me if the patch type is defined
> within the patch itself.

...or unambiguously and tamper-resistant derivable from the patch itself.

This is a strong argument against having plug-ins.  However, there are
several ways in which this could be remedied:
 * Enforce that the repository also stores all implementations for all
   used non-standard patch types.
 * Have a central site of trusted plug-ins, perhaps with some kind of
   hash or signature that is also stored in all patches.
 * Have a central plug-in test suite, so that every client can check
   whether a new plug-in really works the way it should.
But still, I agree that this is the weakest point in my story.

> which probably
> means a domain-specific language.  Using an ordinary interpereted language
> for this purpose would open up way too many security holes, plus you don't
> want that much generality.

As shown above, that domain-specific language would have to be fairly
powerful, so some generality is necessary.  Rather than invent Yet Another
Language, I think a good option is to use some general-purpose language,
where the execution of the plug-in code can be 'sandboxed' to prevent
security holes.  (If such an enviroment exists...)

[snip]
> So I'm thinking there may be two parts to each patch:
> 
> 1) File breaker--breaks the file into multiple parts (e.g. lines for
normal
> hunk patches).  Also with a corresponding un-breaker.
> 
> 2) Chunk modifier--modifies the specified parts of the file (counted in
> terms of parts broken by the file breaker).
[snip]

That's an interesting idea-- let me think about that some more.

> As far as how to acheive it, we'd first need to understand what we want to
> do better than we do now (unless you understand it better than I do... :).
> Then we'd need to rewrite the existing patches in terms of the new
> understanding, to show that the commutes can be computed without
> hard-coding them by hand.  Then we'd need to define a few more patch types
> using the easy-extensibility features previously developed (to
> show/determine whether they are sufficient for our purposes).  Finally
we'd
> want to define a domain-specific language and interpereter, to allow the
> patches to be defined extensibly.
> 
> At least that's how I imagine things would progress.  I'm not sure this is
> the best solution, but it's the best I've thought of.

This is a sensible development path.  I won't have time to contribute much
code, but I'll try to keep the ideas coming your way :-)

> In general, commutation is very hard to figure out.  It may be that an
> algorithm exists to do so, but I don't know about that.  So this sort of
> extensibility seems pretty far out.
[snip]
> > (I have a rough idea, I'll try to write that up for a separate post if
there
> > is interest.)
> 
> I'd be interested.

Watch this space :-)

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