Re: IDE

[Lluís <xscript@gmx.net>]

Przemysław Wojnowski writes:

> W dniu 16.10.2015 o 12:27, Dmitry Gutov pisze:
>> On 10/16/2015 10:39 AM, Przemysław Wojnowski wrote:
>> 
>>> IIUC someone developing an EDE support (a plugin?) for a build tool can
>>> provide as many as s/he wants, right? For example for a build tool a
>>> developer may provide only two definitions: clean and build.
>> 
>> No, they'll have to extend every relevant project type (thus creating new
>> types), and in each of them, define clean and build. Or something along these
>> lines.
>> 
>> Any user-defined types will miss out, because the author of the build tool
>> support is not aware of them.
> IIUC you suggest to use the Bridge Pattern to separate Project Type and Build
> Tool abstractions and allow to exchange them independently, right?
> IMHO this is good design and maybe EDE is already built is such way (I'll have
> to use and read EDE first to get better understanding of it.)

Hmmm, I think I should read about that pattern more closely, but AFAIK this is
not what EDE uses. EDE is built around a class hierarchy of ede-project that
provides all the information and actions you might need for each type of project
and all possible operations and information sources on it.

But this bridge pattern does seem to match what I had in mind, though (I made up
the names just now):

* 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.

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

* 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.

* project: A specific project built from a combination of project types. For
  example, an autotools project with some customized project type that overrides
  some of it. This would be what other tools use to interact with each of the
  services supported by the project.

This scheme is something I've had on the back of my mind for quite some time in
order to make EDE easier to develop for and for users to add persistent
customizations on top of existing project knowledge.


Thanks,
  Lluis

-- 
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth