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

Previous Next

Full log

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

From: Philipp <p.stephani2 <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
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, 5 Sep 2021 19:14:29 +0200

> Am 18.07.2021 um 02:53 schrieb Dmitry Gutov <dgutov <at> yandex.ru>:
> 
> On 05.07.2021 22:05, Philipp wrote:
> 
>>> 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.

I think the idea is applicable to most programming languages that have some form of subtype polymorphism.  Basically, for a normal (monomorphic) function, you can make the parameter types more general or the return type over time more specific over time without breaking compatibility.  For a polymorphic function that's only specialized but not called outside the defining entity, e.g. a private virtual function in C++ or a method marked as @ForOverride (https://github.com/google/error-prone/blob/master/annotations/src/main/java/com/google/errorprone/annotations/ForOverride.java) in Java, it's the other way round: you can make the parameter types more specific and the return type more generic over time.  That implies that for a polymorphic function that's also called outside the defining entity, you can't change any of the types without breaking compatibility.  Thus the suggestion to separate the interface for callers from the interface for subclasses/specializers.

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

I guess you also can't introduce new parameters without breaking compatibility either.  That would only leave the new method possibility.  We could then say that nothing outside project.el should call it to avoid the above problem.  Ideally, the byte compiler would support a declaration form similar to @ForOverride to warn about such invocations.

Previous Next

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