Hacker News new | ask | show | jobs
by adlawson 4359 days 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.
1 comments
PeterGriffin 4359 days 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.

link
Gigablah 4359 days 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/interna...

link
PeterGriffin 4359 days 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.

link