Re: A unified project root interface

["Eric M. Ludlam" <eric@siege-engine.com>]

On 03/20/2013 01:47 PM, Stefan Monnier wrote:
>>> [ Actually, there are various reasons to split EIEIO, one of them would
>>> be to try and fix the eval-and-compile mess.  ]
>> What do you mean by "splitting EIEIO"? Into what parts?
>
> Sorry, I mostly meant "split eieio.el".  What parts?  Well, that's
> a good question.  I think if I knew, I'd have done that already ;-)
> Maybe a first split would be "all the code in eieio.el up until the end
> of the first big eval-and-compile".
> At least, if the aim is to get rid of those nasty eval-and-compile.

This email, and browsing in eieio.el in the CEDET repository gave me an 
a-ha moment.  I think I know how to "split" eieio such that the 
eval-and-compile elements are fixed, and have a much nicer eieio.el in 
the process.  My initial experiments show I'm on the right track.

David, is there something that needs merging from Emacs to CEDET I need 
to worry about before making massive structural changes in EIEIO?

>> This won't work; you cannot detect whether a file is part of a project
>> without the project's definition (which comes in the form of a class, as
>> I've already written). It's a chicken/egg thing.
>
> I don't think so.  The first part of the detection is to look for the
> tell-tale files (.bzr, .dir-locals, Tupfile, you name it).
>
> The project definitions can setup some side table that can be preloaded
> and used by a function that looks for those files.
>
> Some of those files will be frequent enough that we may also want to
> preload some additional predicate that checks whether we really need to
> load "the rest".

I think all David is trying to say is that the EDE project detection 
system uses EIEIO classes to hold the match data.  For example, the 
class instance contains the name of the key file to look for that 
identifies the project.

If the goal is to use EDE's detection scheme and data, but not load EDE 
project classes, then we are all set already since the EDE project 
classes are not directly involved in detecting the projects.  If the 
goal is to not use EIEIO at all, then we'd end up just using a plist 
other random data structure instead of using EIEIO to do it.  This 
wouldn't be a big deal because AFAIK, these classes aren't subclassed, 
so impact would be small.

In both cases above, we'd need a simple mechanism to disable the loading 
of EDE project classes, and using a placeholder in the project cache 
instead.

Alternately, perhaps I can find out why EIEIO isn't acceptable, and fix 
that instead.

Eric