Re: IDE

[Dmitry Gutov <dgutov@yandex.ru>]

On 10/16/2015 07:47 PM, Lluís wrote:

> * service-type: A type of service (one instance per type), like build, find root
>    directory, include search paths, compilation flags, etc.
>
> * service: A specific implementation of a service type, like using vc-dir for
>    finding the root directory of a project.

This sounds good. The implementations could be different (e.g. Java-ish 
Service Locator [0]), but in the absence of other requirements the 
closest Emacs idiomatic structure would be a hook (list of functions) 
for each service type. Like project-find-functions, for example.

Note that the objects the latter currently returns provide both "find 
root" and "search path" services. Thus far it seemed to make sense. Can 
one, and would one want to create different search-path services working 
with the same find-root service? That's an interesting question, and I'd 
love to see a practical example.

More generally, if a package P registers services A, B and C, if B needs 
some information from A, would we expect them to go through P-internal 
channels, or the public interface? For instance, most services might 
like to know the project root (let's call that service type R).

We could standardize the dependencies like that. In the simplest case, 
all services depend on project-root (except for itself), and we'll pass 
the current project-root instance to each functions in their hooks. Then 
an element of service-b-functions will only return non-nil if that 
implementation of B can work with the given kind of project-root (or 
simply "project"; we might include some more info into that instance as 
well).

On the flip side, if there are no B implementations that can work with 
the currently detected R service r1, but there's a certain b2 in 
service-b-functions that would work with r2 (currently shadowed by r1), 
we may be missing out.

> * service-collection: A set of service implementations of the same service
>    type. This allows aggregating results from each service into a single answer.

I suppose you can get this from the same service-b-functions hook, if 
you treat it in a different way.

> * project-type: A type of project defines the service collections it provides
>    for each service type it knows about. An example could be an Emacs project
>    (knows how to auto-detect it, things like the build system it uses, etc.), and
>    Android project, a Linux kernel project, an autotools project, etc.

Having to declare each combination of service-types that a project can 
provide still seems unnecessarily limiting (and tedious). But that's 
what project-types would be for, right?

How would a client even use those declarations? If we were to go that 
way, it'd be better to simply have a project instance have a method that 
returns a list of all services it supports. Or, even simpler, return a 
nil or raise a not-implemented error in each of the generic methods it 
doesn't implement.

Next, suppose a project instance can tell whether it provides a "build 
tool" service. What does a "call build task" command does? Looks for the 
current project and gives up if it doesn't provide the required service, 
or specifically asks the locator for a project implementation that does 
provide that service?

In the latter case, we potentially buy more functionality, at the cost 
of having different commands disagree about what the current project 
actually is.

> Thanks,
>    Lluis
>

[0] http://martinfowler.com/articles/injection.html#ADynamicServiceLocator