[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Subprojects in project.el

From: João Távora
Subject: Re: Subprojects in project.el
Date: Fri, 25 Nov 2022 23:55:57 +0000
User-agent: Gnus/5.13 (Gnus v5.13)

Dmitry Gutov <dgutov@yandex.ru> writes:

> No, again, he just wanted to show a quick example. With pseudocode,
> almost like.

It was real, working code.  The only thing that was missing was uniform
way to take advantage of the new structure in the user commands to find
files, grep strings and run compilation commands.  Also, the follow-up
message showed that it's possible to have the new logic and not use any
internal data structures "from the outside".

>>> The program that creates instances of 'vc' type is called
>>> 'project-try-vc'. But we could similarly add a generic method belonging
>>> to the same unit of code (called 'project-subprojects') which would
>>> "belong" to the VC project backend and create a list of instances of its
>>> type.
>> Again, you are talking about project kinds already supported by
>> project.el
>> as its built-ins.  I'm asking how to produce a project of a custom type.
> To produce a project of custom type, you decide the data structure for
> that type, write implementations for all the required (and perhaps
> some optional) generic methods, then create that structure.
> You asked, however, how to instantiate a project of a type belonging
> to "someone else". But didn't explain why.
> In most cases we will say it's not a good idea, but when a practical
> goal is described we will decide to either say "go ahead, it's okay in
> this case", or, hopefully, suggest a different way to reach that goal
> (just like I did with the 'project-parent' definition example). Or
> rethink and throw away the whole design (hopefully not).

I don't think it has to be so extreme.  I don't understand why there
isn't a user-callable construtor for a type of project that is currently
represented by the '(transient . "<dir>") implementation detail.
Demanding that the users of looking to add to project-find-functions
additionally define a whole new type and all the operations to go with
it is unreasonable, IMO.  I don't think it's "throwing away the whole
design" to provide one such constructor or a means to simplify this.

Even better, provide a CLOS class, so that users may subclass it and use
inheritance in the CLOS generics.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]