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
Show HN: Virtual File System in PHP
11–20 of 28 posts
Re: Show HN: Virtual File System in PHP
#12Earlier quoted context omitted.
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 hav…
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.
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.
Re: Show HN: Virtual File System in PHP
#13I'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.
Re: Show HN: Virtual File System in PHP
#14I know PHP isn't the "coolest" of languages around, but I thought I'd just show my project I started a few years ago and never really got around to finishing. 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…
Very cool project. This pushes the bounds of what I expect, especially from php.
Re: Show HN: Virtual File System in PHP
#15Re: Show HN: Virtual File System in PHP
#16Earlier quoted context omitted.
https://github.com/adlawson/vfs.php#example-use-cases
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:
```
FileSystem::factory('vfs://');
file_put_contents('vfs://foo.php', 'require 'vfs://foo.php'; // Hello, World!
```
Re: Show HN: Virtual File System in PHP
#17I know PHP isn't the "coolest" of languages around, but I thought I'd just show my project I started a few years ago and never really got around to finishing. 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…
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)
Re: Show HN: Virtual File System in PHP
#18I 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.
Re: Show HN: Virtual File System in PHP
#19I know PHP isn't the "coolest" of languages around, but I thought I'd just show my project I started a few years ago and never really got around to finishing. 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…
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!
Re: Show HN: Virtual File System in PHP
#20Earlier quoted context omitted.
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.
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 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...