Re: Re: [PEPr] Comment on Web Services::Services_Digg

Peter Beckman wrote: > On Sun, 22 Apr 2007, Gregory Beaver wrote: > >> However, I suggest starting out as alpha, and breaking BC to take >> advantage of features in 5.2 as time goes on. > > Is there a way for PEAR upon installation to detect if the person has > PHP4 > or PHP5, then select the latest version of a package that is compatible > with that version? > > While I don't think this exists already, it would make it easy for an > author to maintain a single package, but stop maintaining the legacy > code > at some point. > > IE, HTTP_Request might be available for PHP4 users through version 1.47, > but after 1.47 it goes to 2.x and only PHP5 users can use the 2.x > version. > > When a PHP4 person does a pear install HTTP_Request they would get > version > 1.47 and a note saying while this is not the latest version, it is the > only available version for PHP4. > > Just a thought; I hate the idea of creating a new HTTP_Request package > called something else for breaking backwards compatibility; now there > are > two packages to maintain, etc. Hi Peter, I have been wrestling with this problem for a couple of years. So far, here is what I've come up with: If there is a way for the package to maintain 100% BC, then what you're suggesting would be a possibility. Here's a scenario the explains why: Let's say the user has PHP 4.4.1, and has an application installed that uses HTTP_Request. He is limited to 1.47, but doesn't pay much attention to this. One day, he updates to PHP 5.2.2. On the next upgrade, he suddenly has HTTP_Request 2.x, and his application stops working. "What happened?" he says. The problem here is that BC includes error handling. PHP 4.x-based packages use PEAR_Error, which is not E_STRICT-compatible. PHP 5.x-based packages use PEAR_Exception. All calls to PEAR::isError() will not work, exceptions will simply bubble up until it his the global exception handler. Code based on PHP 4.x is intrinsically not backwards compatible with PHP 5.x. So, although what you're suggesting is technically possible, and I in fact have implemented REST to make it possible to do, there are significant hurdles to making it work. All packages who take advantage of this feature would have to provide a compatibility layer that would transform exceptions into PEAR_Error, and mimic the exact API of the other package. In other words, a whole lot of unnecessary work would be involved, and what was a convenience feature suddenly becomes a royal pain in the ass. I don't yet see any way around this problem either, although I'm always on the lookout for a better idea. Greg