4 ms·

I 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.

• aceperry 12y ago
  Very cool project. This pushes the bounds of what I expect, especially from php.
  • encoderer 12y ago
    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 https://github.com/shaneharter/PHP-Daemon)
• Gigablah 12y ago
  Hm, I wonder if I can marry this with Flysystem (https://github.com/thephpleague/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!
  • jlogsdon 12y ago
    You can use PHP built-in functions. Check out the readme. The API is shown alongside using functions like file_put_contents and require.
    • Gigablah 12y ago
      I know, I'm referring to using those built-in functions in place of Flysystem's API. Basically a proxy.
• PeterGriffin 12y ago
  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.
  • adlawson 12y ago
    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.
    • PeterGriffin 12y ago
      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.
      • Gigablah 12y ago
        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/internal.html http://phpdoc.org/docs/latest/references/phpdoc/tags/interna...
        • PeterGriffin 12y ago
          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.