[2 days left] What’s wrong with your cloud strategy? Learn why multicloud solutions matter with Nimble Storage.Register Now


Questions about converting existing PHP class to Composer package..??

Posted on 2014-02-16
Medium Priority
Last Modified: 2014-02-20
I have an existing PHP class library on GitHub that consists of a parent class and a few child classes.  I'm just learning about Composer and I'm trying to convert this to a package.

From what I've read, it looks like the first step is going to involve restructuring my directories to follow the PSR-0 standard.  Is that accurate?

If so, that's going to be quite a drastic change to my class, so I'm wondering if I should update my existing GitHub repo or create a separate one altogether..??  Seems like such a drastic change could cause issues for people using my current class if they pull from GitHub not realizing so much was different.  

On that note, how far do I need to go with it?  Right now my structure is old, basic structure where my config file and my class files are in /includes.  Then the classes are named things like paypal.class.php, paypal.adaptive.class.php, etc.  

Well, it looks like this PSR-0 standard is wanting something more like /angelleye/PayPal/PayPal.php, where my class name would just be PayPal instead of paypal.class.php.  And then it looks like I should go with PayPal_Adaptive.php as my adaptive class name, which would then turn into something like /angelleye/PayPal/PayPal/Adaptive.php..??

I'm just not sure I'm following that entirely right, and again, if I am, it seems like maybe this needs to be an entirely separate GitHub repo..??

Also, once I do this, will people that are not using composer still be able to use the class library, or does this make it a composer only type of thing so I'd still have to maintain two separate versions of my class?  I know I have lots of people using my class that are novice and intermediate developers and may not know about or want to use Composer, but would rather just download and include themselves like they always have.  

Any information on if I'm headed down the right track or not would be greatly appreciated.  Thanks!
Question by:Andrew Angell
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
LVL 111

Accepted Solution

Ray Paseur earned 1500 total points
ID: 39864375
I think I would make a separate repository.  This is a big change from what many of your users may be accustomed to, and it will require them to restructure their libraries.  That's not an upgrade, it's an incompatibility (even if it leads to better things).  It also creates twice as much work for you, and to that end, I would deprecate the old repo so you can leave it in the steady state and concentrate your development on the new version.

Suggest you leave this question open for day or two to see what others have to say about it.

Best regards, ~Ray
LVL 11

Author Comment

by:Andrew Angell
ID: 39864407
Thanks for the info, Ray.  So it sounds like I've got the general idea correct then..??

One thing I'm a little confused about, too, is how to handle config files with this sort of setup..??  Right now my library has that /includes folder with a basic config file (not a class) and then my actual class files, too.

So if I make this change I'd move the class files into something like /lib/angelleye/PayPal/, but would my config file still stay this way or does it need to be converted into an actual class, or how does that get handled exactly?  

Again, any info is appreciated.  Thanks!
LVL 111

Expert Comment

by:Ray Paseur
ID: 39864446
Yes, I think you have the general idea right on.

If I understand your config file correctly, it would probably become a class that the other classes would extend.  There is never a perfect solution for things like that.  A lot of the current thinking seems to hover around "dependency injection" but this has a feel (to me, at least) like multiple inheritance.  It can create more complexity than it relieves.  Anything we can do that favors convention over configuration makes our software easier for others to use.  At least we can put all of the configuration switches in one script :-)

I've never jumped into composer, so I'm a little unclear about some aspects of it, but I think the idea of include() files goes away in favor of an autoload strategy that is based on structured names.  Beware of case-sensitivity in the names.  You might also want to read a bit about autoload() and spl_autoload_register()

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Part of the Global Positioning System A geocode (https://developers.google.com/maps/documentation/geocoding/) is the major subset of a GPS coordinate (http://en.wikipedia.org/wiki/Global_Positioning_System), the other parts being the altitude and t…
Introduction This article is intended for those who are new to PHP error handling (https://www.experts-exchange.com/articles/11769/And-by-the-way-I-am-New-to-PHP.html).  It addresses one of the most common problems that plague beginning PHP develop…
The viewer will learn how to look for a specific file type in a local or remote server directory using PHP.
The viewer will learn how to create and use a small PHP class to apply a watermark to an image. This video shows the viewer the setup for the PHP watermark as well as important coding language. Continue to Part 2 to learn the core code used in creat…

656 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question