Show HN: Virtual File System in PHP(github.com)
github.com
Show HN: Virtual File System in PHP
https://github.com/adlawson/vfs.php
9 comments
Hm, I wonder if I can marry this with Flysystem (https://github.com/thephpleague/flysystem) so I can use PHP builtin functions rather than being tied to their API.
Maybe I'll give it shot!
Maybe I'll give it shot!
Very cool project. This pushes the bounds of what I expect, especially from php.
One nice upside to the (often negative) impression of PHP is that when you put in some time and produce something kinda cool, you get a lot of positive attention from the community. I experienced this myself on a project to create a multi-processing library for php (https://github.com/shaneharter/PHP-Daemon)
I didn't have time to review the project in detail, but one thing that made an impression on me is having a registry in there.
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.
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.
I absolutely agree with you about applications using their own DI/IOC implementations.
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.
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.
Oh I see.
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.
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.
I personally think it's neater to mark the class with an @internal PHPDoc tag rather than add a sub-namespace.
http://phpdoc.org/docs/latest/references/phpdoc/tags/interna...
http://phpdoc.org/docs/latest/references/phpdoc/tags/interna...
It's an option, and it sure is neater to those creating the library, but it's much less neater to those using it. Not everyone compiles a PHPDoc for themselves when downloading a library, so then all classes form a nice big pile at the root namespace.
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.
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.
I don't much care for PHP, always using perl in the old days when given the choice, but I sure do wish the PHP I've had to work with over the years looked like this.
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 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.
Thanks very much :)
How does this compare to vfsStream[1]? I've used that in the past for mocking in unit tests. Does this offer anything more than vfsStream?
[1]: https://github.com/mikey179/vfsStream
[1]: https://github.com/mikey179/vfsStream
On the surface of it, there is no real difference. You can use them both with your usual `fopen` and `file_get_contents` builtins.
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...
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...
I'm curious if this would be performant enough to use in something like Heroku. For example a big challenge to running Wordpress on Heroku is that some plugins write out some files, etc
I don't see why not. It only loads a few objects into memory so the footprint would be tiny, especially when you compare it to running WP.
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.
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.
PHP may be an ugly language, but these kind of projects are fascinating even if i doubt that i would ever need such a thing. And +1 for that gif.
I made one some time ago too
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.
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.
I am curious, what is the point of using something like this?
How exactly do you perform runtime php evaluation using this?
You write your php to a file in the vfs, then you `require` it back out.
There's an example of it in the documentation[1] but a simple example could be:
```
<?php
FileSystem::factory('vfs://');
file_put_contents('vfs://foo.php', '<?php echo "Hello, World!";');
require 'vfs://foo.php'; // Hello, World!
```
[1]: https://github.com/adlawson/vfs.php#documentation
```
<?php
FileSystem::factory('vfs://');
file_put_contents('vfs://foo.php', '<?php echo "Hello, World!";');
require 'vfs://foo.php'; // Hello, World!
```
[1]: https://github.com/adlawson/vfs.php#documentation
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.