Closed nlzet closed 9 years ago
Thanks for this. Forgive me being slow, as I've never used an IDE - all this is to allow for IDE autocomplete? So you can find a detection name without having to look at the docs?
I'm not opposed to the idea, but I wonder if there's another way to achieve the same end result. My main reservation is that the Morse class now needs to have knowledge of each of the detections in the Feature classes. It breaks the separation between the two.
So I think we should explore ideas that either:
Any ideas?
No problem. Well, there are a lot of directions to go, but here are some thoughts i considered:
exec
function within the System
classPHP 5.4
__call
on the morse class, and using PhpDoc
's @method
to reveal all features.
I'm definitely not saying my current solution is the best, but like i t is now, you have to know the correct string like system/exec
, that doesn't seem right. IMO it would even would be better if you just have to call one method like Morse::featureExistsCacheApc()
or maybe something like Morse::getCache()->existsApc()
. (Altough the last proposal raises the same issue that I mentioned in 1.)
I feel a bit like this is the tail wagging the dog. Refactoring a loosely coupled design into a tightly coupled one just to enable IDE autocompletion seems like too much.
I don't think you're wrong in that this could be needed, but I'm also not convinced of it.
Ok no problem, you may then close this PR.
I appreciate your contribution - thank you.
I added all current available feature detections as a constant on the Morse class. This allows an IDE to auto complete to easily find a feature. As this library will grow something like this seems to be necessary. This will allow:
I also added a test class which will check all available feature detections to ensure a constant with the correct name is available and has the correct value