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
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.phpOr 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
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
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
Le 12/11/2020 à 23:01, Larry Garfield a écrit :
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