bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#47799: 28.0.50; Default `project-files' implementation doesn't work


From: Dmitry Gutov
Subject: bug#47799: 28.0.50; Default `project-files' implementation doesn't work with quoted filenames
Date: Sun, 18 Jul 2021 03:53:55 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 05.07.2021 22:05, Philipp wrote:

What I was also thinking of previously, is some "fileset" data structure which 
could contain a list of local file names and their connection in a separate slot. Maybe 
even separating the parent/root directory into a separate slot when feasible, to minimize 
GC further, though that might complicate applications.

A more structured "file" value format might make this stuff easier to use 
indeed, and perhaps the performance difference will be negligible.

I think those are very good ideas.  The "fileset" structure sounds like a 
pretty good abstraction.

I've yet to express that in terms of code, though.

The difficulty is having a method like project-files return one format for some 
users, and another for users who want to take advantage of this performance 
improvement. Or we break the compatibility and/or introduce a new method with 
this new behavior.

A general design approach in OOP is to not treat abstract virtual functions (generic functions in ELisp terminology) as part of the public interface of a type; i.e., abstract functions can be implemented, but shouldn't be called outside of the module that defines them (project.el in this case). That allows for changes like this: implementers could freely return the new fileset structure because only project.el would call project-files. Not sure how much ELisp code adheres to this principle, though.

When you say "abstract virtual functions", do you mean OOP as in C++ OOP? I'm not sure about standard practices there, but this sounds more like C++ and less like OOP in general.

I'm looking as generic functions here as part of an interface signature (like Java or Go interface). They are programmed against (which is the case with project.el) and are supposed to be stable.

> If there's too much code (outside of project.el) that relies on project-files returning a list, we need to indeed fall back to some of the other options.

A new method seems to be the way forward. Or, say, an ad-hoc argument which determines whether file names should be relative.





reply via email to

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