Re: A unified project root interface

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

On 03/21/2013 12:32 PM, David Engster wrote:
> Eric M. Ludlam writes:
> W>  On 03/20/2013 01:47 PM, Stefan Monnier wrote:
>>> 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?
>
> No, it's all already merged to upstream, including the renames by
> Stefan.

Great!  Thanks.

>> 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.
>
> Let's talk examples, then. Say we have
>
>   (ede-project-autoload "vcs-root"
> 		       :name "VCS ROOT"
> 		       :file 'vcs-root
> 		       :proj-file 'ede-check-for-vcs-dirs
> 		       :proj-root 'ede-vcs-root-dir
> 		       :proj-root-dirmatch "NONE"
> 		       :class-sym 'ede-vcs-root-project
> 		       :load-type 'ede-vcs-root-load
> 		       :new-p nil
> 		       :safe-p t)
>
> So from that we'd take the list of slots, which is practically a plist,
> and would write something akin to ede-dir-to-projectfile, but using
> plist-get/set instead of oref/oset?

Yes, basically.  Seems odd to swap one data type form for another, but 
there it is.  Since the class name is used as a function, no code using 
it will need to change.  Perhaps.

> And what would happen when `ede-check-for-vcs-dirs' returns t?  Would
> that load EDE then, or would we try to go on to provide the basic
> functionality (like getting the root) with a class-less version?

I think this will be a bit of a challenge.  The project detection, and 
then project hash are the key important pieces.  If the goal is to get 
something that will be dumped w/ Emacs, and Fast, we'd need to start by 
refactoring ede/files.el to split out the parts that track the 
directory-to-project associations from all the misc EDE related file 
finding routines.

Once that is working, I had originally thought we could use the 
ede-project-placeholder as a starting point since it was designed to be 
swapped out for a real project later, but that is still an EIEIO class.

Instead, probably another small list left as a buffer-local variable 
that can be tracked.  I imagine it would hold the root of the project, 
and some misc :key describing the nature of the matched project.  That 
would be used instead of ede-object for quick project detection.  I 
think it would also need a couple new hooks, including 
ede-new-project-detected-hook.  EDE would use that to actually load a 
project instead of doing so directly from the auto-loader.

Another option is to hand-craft an EIEIO object vector.  They are all 
just vectors, so if we had an EIEIO class that had a small number of 
slots (smaller than the existing placeholder object) it could be created 
by hand with (vector ... ) and used to track projects.  Once EIEIO was 
loaded, more complex code could just keep using it, but as an object.  I 
wouldn't do that if there were more than 2 or 3 slots in it though.  As 
code changed, the indices might change, and maintenance would be a pain. 
  As for a transition strategy though, it might make things easier.

As for ede-check-for-vcs-dirs, it would need to provide data to the 
auto-loader that doesn't need to be called to detect the project.  There 
is a bit of logic that says "If the :file isn't loaded yet, try this 
other thing".  That way if it is loaded, it can use one of the handy 
functions which often have caches of their own for detection and makes 
things faster.

On the flip side, perhaps this is an opportunity to simplify.  There is 
a bunch of historical baggage in the loader.  I'll bet there are some 
options that could be fixed/removed, simplifying the whole thing.

Anyway, the key is that the autoloader could be recycled into something 
EIEIO free, and a simple hook would give EDE what it needs to keep 
going, without it's current custom autoloader, and it might be possible 
to keep old registration fcns working in the process.

Eric