GNU bug report logs - #47799
28.0.50; Default `project-files' implementation doesn't work with quoted filenames

Previous Next

Full log

Message #47 received at 47799 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: 47799 <at> debbugs.gnu.org
Subject: Re: bug#47799: 28.0.50; Default `project-files' implementation
 doesn't work with quoted filenames
Date: Sun, 18 Jul 2021 03:53:55 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.