Why there is no StreamWrapper interface ?

php.internals

Pierre

5 years ago
Hello all, This might be a stupid question, or it may have already been answered tons of times, but is there any valid reason for not having a StreamWrapper interface as documented there: https://www.php.net/manual/en/class.streamwrapper.php Or if some methods are optional, multiple interfaces, or if all methods are optional, an abstract base class in PHP standard library ? Regards, Pierre

Sara Golemon

5 years ago
On Thu, Nov 12, 2020 at 7:00 AM Pierre <pierre-php@processus.org> wrote:
> This might be a stupid question, or it may have already been answered > tons of times, but is there any valid reason for not having a > StreamWrapper interface as documented there: > https://www.php.net/manual/en/class.streamwrapper.php > > Or if some methods are optional, multiple interfaces, or if all methods > are optional, an abstract base class in PHP standard library ? > >
Many methods are optional, but more generically it's that user-space wrappers date to PHP 4.3 and like... did we ever HAVE interfaces at that point? Or abstract classes? It was a different time, man. You were there, you know what it was like... Honestly, I kind of regard the state of PHP's filesystem libraries to be one big hot mess. I'd really much rather redesign them from the ground up with some BC shims to avoid breaking the world, but I lack the drive to make that happen at the moment. -Sara

Benjamin Morel

5 years ago
On Thu, 12 Nov 2020 at 19:28, Sara Golemon <pollita@php.net> wrote:
> Honestly, I kind of regard the state of PHP's filesystem libraries to be > one big hot mess. I'd really much rather redesign them from the ground up > with some BC shims to avoid breaking the world, but I lack the drive to > make that happen at the moment. > > -Sara >
There have been some attempts (including mine) to design a better abstraction on top of current PHP filesystem functions, which would be a good start, but I think what's missing the most currently is a good API to get inspiration from. Is there a filesystem library in another language that is considered state-of-the-art at the moment? — Benjamin

Larry Garfield

5 years ago
On Thu, Nov 12, 2020, at 3:25 PM, Benjamin Morel wrote:
> On Thu, 12 Nov 2020 at 19:28, Sara Golemon <pollita@php.net> wrote: > > > Honestly, I kind of regard the state of PHP's filesystem libraries to be > > one big hot mess. I'd really much rather redesign them from the ground up > > with some BC shims to avoid breaking the world, but I lack the drive to > > make that happen at the moment. > > > > -Sara > > > > There have been some attempts (including mine) to design a better > abstraction on top of current PHP filesystem functions, which would be a > good start, but I think what's missing the most currently is a good API to > get inspiration from. > Is there a filesystem library in another language that is considered > state-of-the-art at the moment? > > — Benjamin
I have heard very positive things about Rust's file system API, but have no experience with it myself. --Larry Garfield

Pierre

5 years ago
Le 12/11/2020 à 23:01, Larry Garfield a écrit :
> On Thu, Nov 12, 2020, at 3:25 PM, Benjamin Morel wrote: >> On Thu, 12 Nov 2020 at 19:28, Sara Golemon <pollita@php.net> wrote: >> >>> Honestly, I kind of regard the state of PHP's filesystem libraries to be >>> one big hot mess. I'd really much rather redesign them from the ground up >>> with some BC shims to avoid breaking the world, but I lack the drive to >>> make that happen at the moment. >>> >>> -Sara >>> >> There have been some attempts (including mine) to design a better >> abstraction on top of current PHP filesystem functions, which would be a >> good start, but I think what's missing the most currently is a good API to >> get inspiration from. >> Is there a filesystem library in another language that is considered >> state-of-the-art at the moment? >> >> — Benjamin > I have heard very positive things about Rust's file system API, but have no experience with it myself. > > --Larry Garfield >
As Larry said, Rust one is probably a good example, but if I remember correctly, Swift's one is not bad too. Java NIO is probably a good contender as well. But Rust has in my opinion a much better error handling than PHP ever had, so I guess it's easier to have a good implementation for such error prone API (you're too dependent on the OS and hardware for managing files safely, you need a seriously robust error handling for this). I don't trust PHP on that front because you are basically just allowed to ignore and not catch any error and let everything burn without worrying. I think that for a robust file handling API, you probably need something much more strict that forces you to do things well. In that regard, anything such as an option type along with enum errors and a pattern matching would do the trick. Anyway, from my own point of view, when I work with files, the two most important features are a good error handling that cannot be missed (returning false silently when something doesn't work is not a good error handling for me) along with guarantee that operations are atomic whenever possible accompanied with doing everything in streams for performance and memory's sake. Actually, error handling put aside, that's what PHP's file handling is, I guess, but I'm far from being an expert on that topic. That was my two cents, my opinion is that PHP should improve its type system and error handling before starting to improve its I/O standard library. Regards, Pierre