One might argue that -f returning Failure is like a SQL query returning NULL, which is appealing to me.
On Fri, Sep 29, 2017 at 4:05 PM, Mark Montague <m...@catseye.org> wrote: > On 2017-09-29 09:53, Parrot Raiser wrote: > >> -e is fairly easy. It asks if something exists. Ignoring Schrodinger, >> either it does (i.e True) or it doesn't. (False) >> -f is more ambiguous. It asks if something has a property (fileness) >> or not. If it exists, it either does or doesn't. [...] >> >> Bash appears to err on the pragmatic side, returning "fail" for both >> -e and -f on a non-existent file. >> > > But that's not what Bash (and the original implementation, /bin/test) do. > From "man test": > > -e FILE > FILE exists > > -f FILE > FILE exists and is a regular file > > The problem is that Perl 6 is currently asking "is something a regular > file?" which leads to this debate about what should happen if the thing > doesn't exist. I think it would be easier and clearer if Perl 6 instead > adopted the standard meaning /bin/test, Bash, Python, and other languages > use. This is arguably the most common thing to test for, and it is also > what most programmers will expect (principal of least surprise). I the > less common case where someone wants to do different things depending on > whether something does not exist or is/isn't a regular file, then instead > of calling $file.f and differentiating between two non-True values, I think > the code would be clearer if they tested $file.e first and then $file.f -- > this should be nearly equal in efficiency since the file metadata (the > results of the stat() system call on POSIX-like operating systems) should > be cached. > > In other words, I think we should change the Perl 6 spec to define .f as > "exists and is a file". > > -- > Mark Montague > m...@catseye.org > -- Fernando Santagata
