Re: cl-defgeneric vs random funcall in project.el

[Stephen Leake <stephen_leake@stephe-leake.org>]

Dmitry Gutov <dgutov@yandex.ru> 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