Show HN: Virtual File System in PHP(github.com) |
Show HN: Virtual File System in PHP(github.com) |
It's been used before as part of a mustache template runtime evaluator and in test suites.
Current issues:
- Test coverage is okay but could definitely be improved (currently ~60%)
- Symlinks
- Proper support for perms/ACL
If anyone's got any feedback or wants to contribute, go ahead.
Maybe I'll give it shot!
Many projects make the same mistake. The registry/service locator/DI container or whatever flavor you prefer should be an application concern.
Applications should create this for themselves, and not every library having its own registry just for instances of its own classes.
Similarly you have factories and builders which wrap a constructor and don't add or change anything. You can remove some of that code and focus on the essence of your library. This way it might gain more supporters and contributors.
The registry in this library, however, isn't meant to be a registry used outside of the internals of the library. It's an unfortunate side effect of trying to marry up object instances with PHPs static stream wrapper API.
I don't even care how it works yet, just looking at how well its laid out makes me feel like I can figure it out without much trouble. The comments and variable names alone start to draw me into the "story" as soon as I pop open a file.
We don't say it enough to each other. Well done.
I believe that the implementation is truer to the behaviour of how these builtin functions behave with a unix FS. Amongst some other subtleties, here's some examples:
- vfsStream simply ignores handle modifiers (except for +)[1]
- some effort has gone into showing where errors were triggered in userland code[2]
- node types are represented as `fstat` would see them[3] rather than using simple types[4]
vfsStream works perfectly fine, but if you want to use it more with testing file system operations; the closer you are to a true environment the better. Obviously this project isn't quite there yet, but it should be once a few issues have been ironed out.
[1]: https://github.com/mikey179/vfsStream/blob/master/src/main/p...
[2]: https://github.com/adlawson/vfs.php/blob/master/src/Logger/P...
[3]: https://github.com/adlawson/vfs.php/blob/master/src/Node/Sta...
[4]: https://github.com/mikey179/vfsStream/blob/master/src/main/p...
If you can configure the paths these plugins write to, then you can use VFS. Unless the plugin explicitly uses `file://` or they strip the scheme, but I doubt they would.
https://github.com/thornag/php-vfs
Similarly, I've been trying to make it behave just like the native functions under unix environment. Think the basic assumptions are the same.
```
<?php
FileSystem::factory('vfs://');
file_put_contents('vfs://foo.php', '<?php echo "Hello, World!";');
require 'vfs://foo.php'; // Hello, World!
```
I wish PHP had visibility for classes, oh well.
Do you know what I do, I put everything that's not meant to be used by "the public" in sub-namespace "Internal". So, say "Vendor\Project\..." for public classes and "Vendor\Project\Internal\..." for volatile internal matters.
This means there's no confusion about what people should use, and what's just the guts of the system they shouldn't mess with.
http://phpdoc.org/docs/latest/references/phpdoc/tags/interna...
In terms of neatness and ease of use, I choose like I'd choose how to optimize code - I focus on the parts that get most use. Users of a library are hopefully way more than its maintainers, so it feels like it's worth slightly inconveniencing the maintainers in order to have an instantly clear public interface.