[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Project systems (again)
From: |
Daniel Colascione |
Subject: |
Re: Project systems (again) |
Date: |
Fri, 18 Apr 2014 00:58:54 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 |
On 04/18/2014 12:50 AM, Eli Zaretskii wrote:
>> Date: Fri, 18 Apr 2014 00:07:20 -0700
>> From: Daniel Colascione <address@hidden>
>> CC: address@hidden
>>
>>> FWIW, I'd prefer that you work with EDE developers to improve and
>>> extend what they have;
>>
>> If EIEIO can't be preloaded (or, equivalent morally, autoloaded on
>> find-file), there's no point in pursuing EDE improvements. An EIEIO-less
>> EDE would be an EDE rewrite anyway.
>
> I don't know enough about this: why couldn't EIEIO be autoloaded?
Stefan was against it the last time this issue came up. There are
namespace cleanliness issues as well as deeper issues of functional
appropriateness.
>> Plus, I don't think the problem space really warrants a complex
>> object system: conventional elisp idioms are adequate.
>
> Since EDE is already there, I think this is a moot point. (I believe
> Eric explained why this design was chosen a while ago.)
It's there, but it hasn't seen wide use. The existence of non-EDE
projects like Projectile should tell us that EDE, as it stands today,
isn't well-suited to being a default project system.
>>> starting from scratch (or almost from scratch)
>>> sounds like waste of effort, especially since some of the EDE is
>>> already in Emacs.
>>
>> I really don't want to start from scratch, but I think it's the best
>> option. A project system is one of those systems for which the hard part
>> isn't the coding, but agreeing on having a single interface to the code.
>> I think we need something much simpler than what exists.
>
> Then how about asking the EDE developers to provide an "easy-ede"
> layer which would conceal the complexity for those situations where
> the corresponding power is not needed?
That's what I'm proposing, except that I imagine EDE can sit on top of
that layer, not that that layer could sit on top of EDE.
>> I find the abstractions in EDE to be much more confusing than they are
>> useful. For something that, at its core, ought to be very simple, there
>> are too many concepts --- target, project, sub-project, config, project
>> placeholder, too much shared state, and too few opportunities for ad-hoc
>> customization. The system feels specialized for a project based on
>> nested autoconf files that build C and C++, and the documentation
>> reflects that. I understand that EDE started simple and grew
>> functionality, but this functionality belongs in separate layers, not
>> mingled into the core.
>
> I see your point. However, EDE was added to Emacs with the intent
> that it serves as basis for developing features such as what you have
> in mind. If there's a reasonably practical way of basing your project
> on EDE, I think we should explore that possibility first, even if it
> requires more work on the EDE infrastructure side, because not doing
> so would waste the effort of integrating EDE into Emacs.
I was afraid of an argument of this form --- it's just the sunken costs
fallacy, isn't it? The fact that effort has been put into EDE shouldn't
influence our evaluations of present alternatives. I don't think using
EDE as a base would reduce the amount of needed work. I actually think
it would increase it.
signature.asc
Description: OpenPGP digital signature
- Project systems (again), Daniel Colascione, 2014/04/17
- Re: Project systems (again), Eli Zaretskii, 2014/04/18
- Re: Project systems (again), Daniel Colascione, 2014/04/18
- Re: Project systems (again), Eli Zaretskii, 2014/04/18
- Re: Project systems (again),
Daniel Colascione <=
- Re: Project systems (again), Eli Zaretskii, 2014/04/18
- Re: Project systems (again), Eric M. Ludlam, 2014/04/18
- Re: Project systems (again), Stefan Monnier, 2014/04/19
- Re: Project systems (again), Eric M. Ludlam, 2014/04/19
- Re: Project systems (again), Stefan Monnier, 2014/04/18
- Re: Project systems (again), Alex Ott, 2014/04/18
Re: Project systems (again), Dmitry Gutov, 2014/04/18