[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cl-defgeneric vs random funcall in project.el
From: |
Stephen Leake |
Subject: |
Re: cl-defgeneric vs random funcall in project.el |
Date: |
Tue, 28 Jul 2015 20:00:49 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) |
Dmitry Gutov <address@hidden> writes:
> On 07/28/2015 02:31 PM, Stephen Leake wrote:
>
>> But the default method uses 'project-search-path-function', which
>> elisp-mode sets to `elisp-search-function'; elisp.el does not use
>> cl-defmethod to override project-search-path.
>
> And if a project implementation has to provide its own implementation,
> it's much cleaner, I think, if it only has to deal with
> project-search-path-function, instead of being forced to
> cl-call-next-method.
Well, that's my question. I don't see that as "cleaner"; I much prefer
object dispatching to random funcalls.
Why would it use 'cl-call-next-method'? That would call the
default method, which is wrong; that's why we're overriding it.
> Further, this part seems like it'd be impossible to implement: "A
> specialized implementation should use the value
> `project-search-path-function', or, better yet, call and combine
> the results from the functions that this value is set to by all
> major modes used in the project".
Right. I don't see that as a useful design. Just get rid of it.
Nothing else in project.el currently suggests that
'project-search-path-function' should be a list; the default method for
project-search-path doesn't treat it as a list. What is the use case
for this? I remember seeing something in the email chain; did that get
captured somewhere?
> However, now that we've reached the consensus that project-search-path
> doesn't need to include the directories inside the current project,
I never agreed to that. In fact, I thought the only thing we _did_ agree
on was that project-search-path included the main project. Sigh.
> an implementation will only need to override it if it actually knows
> search-path better than the major-mode.
The "implementation" we are talking about here is presumably something
that knows how to read project files defined by some third-party tool
(Ada .gpr files, gradle files, etc). That would certainly know exactly
what the project search path should be, and it should override all
relevant project-* functions.
As far as I can see, the _primary_ purpose of a project-* implementation
is to provide the correct search-path and/or project-root, so the
functions that use those do the right thing.
>> Why do we need both dispatching methods?
>
> The alternative (which is more feasible now) is to use the context
> specializer, like:
>
> (cl-defmethod project-search-path (_project &context (major-mode (eql
> emacs-lisp-mode))))
That's one alternative.
Another is to have the project backends provide a minor mode, that
specifies the project implementation, by returning the proper value from
(current-project).
Or just let the major mode specify the project backend; that's what
happens in elisp and Ada mode now.
One implementation is to define a buffer-local current-project variable;
that specifies the backend as well as any relevant information.
In any case, we only need cl-defmethod in one form or another.
--
-- Stephe
- cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/28
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/28
- Re: cl-defgeneric vs random funcall in project.el,
Stephen Leake <=
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/28
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/29
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/29
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/30