-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Composer Package and PSR-0 compliance #40
Comments
I'm trying to make the modifications needed for the PSR-0 compliance. Here's what I've got so far : I'm now trying to make the tests pass but Simpletest is just ... well... not the best testing framework. |
We just merged #41 so you should be able to use composer now. We'd also discussed switching from SimpleTest to PHPUnit, I'm going to try to clear out all these issues before considering that though. Switching to namespaces would be nice but would be a big compatibility break so that might need to wait until there's a v3 API. In light of all that I'm going to close this issue. |
I forgot to mention that once I get a few more of these issues sorted out I'll publish a release to packagist, for now you should be able to reference the git repo though. |
Was there any more thought given to making the classes PSR-0 compliant? |
It sounds like a great idea. A pull request which is backward compatible would be accepted. |
@aheckmann, I think the BC is the issue. We'd be basically be renaming all the classes into a new Recurly namespace. Hence my mention of a v3. |
Do you mean backwards compatibility with people already using composer or the people that are including the For the latter, as @JaapRood mentioned, all that would be required is aliasing the classes in |
I see. Yeah if this would break existing APIs we can still do it, just need On Sunday, November 3, 2013, Ross wrote:
Aaron Heckmann |
The PHP community and all the big frameworks / libraries are rallying around the Composer dependancy manager to make it easy to use external libraries within projects. Think of PHP's answer to Ruby's oustanding Gems. As Recurly's PHP client is always used within another context it would be awesome if the library could be slightly altered so it would work as a Composer Package.
Composer, as any proper dependancy manager in my eyes should, has an Autoloader. Now to make sure all Packages load properly, and only classes are loaded that are needed, all the big frameworks and libraries (like Zend, Codeigniter, Symfony2, FuelPHP, Doctrine, etc.) came together and created the PSR-0 standard, which describes a simple classname and file structure strategy.
The Recurly PHP client as already been setup in a way that get's close to PSR-0 compliance, but it would need a couple of adjustments, the biggest of which would be the use of namespaces.
Ofcourse, for users that don't want to use the Composer autoloading and have current applications running on the library, you don't want to break backwards compatibility. The solution would be to make all the classes files PSR-0 compliant and using the existing lib/recurly.php file to alias the newly named classes to the old Legacy names. Composer users will never touch this file and will be able to use the autoloader, and existing users can just keep using everything the way they're used to.
It'd be great to hear if the Recurly PHP Client could work with Composer. It would make implementing Recurly even easier.
The text was updated successfully, but these errors were encountered: