[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A unified project root interface

From: Eric M. Ludlam
Subject: Re: A unified project root interface
Date: Wed, 20 Mar 2013 20:55:04 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]