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. João
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4