Re: Re: [RFC] PHP_Compat, MIME_Type & mime_content_type

On 6/27/05, Philippe Jausions <Philippe.Jausions@11abacus.com> wrote: > Justin Patrin wrote: > > On 6/26/05, Joe Stump <joe@joestump.net> wrote: > > > >>IIRC, Payment_Process only requires PHP_Compat for certain drivers > >>under certain versions of PHP. > > > > No PEAR package should depend on PHP_Compat. The PHP dependency should > > be set at the minimu that works correctly for the entire package. > > PHP_Compat can be used by the person deploying a package to allow the > > package to run on a lower version (assuming the problem is a missing > > function, of course). If one driver in a package requires a much > > higher version of PHP than the rest and the maintainers want the > > package at the lower PHP dependency then they should break out the > > driver into its own package. A PHP_Compat dependency is simply not ok. > > > > I don't remember seeing anywhere on the site how to deal with > conditional dependency on PHP_Compat in a package. > The website may not have anything official on this, I'm speaking my own opinion here. I do stand by it however. > Let's say you want to use a fairly new useful PHP function such as > str_split() (PHP 5) or file_get_contents() (PHP > 4.3.0). Then you need a dep on that version of PHP. This is what I honestly think. We could possibly allow a lower PHP dep if you can do a conditional dependency for PHP_Compat on a lower version of PHP (see my pervious e-mail to this thread) but this is IMHO somewhat of a hack and should be used sparingly. People really should be updating their PHP installations. If they're on a shared host which doesn't update they should leave so that that host falls vy the wayside. There's no excuse for not updating PHP except for BC breaks (i.e. PHP5). > > Should the package itself require_once the > PHP/Compat/function/str_split.php or do you want to let that > responsibility to the end user in their own script? I am suggesting that the user deal with this. Using a function (or a new feature in a function) from a newer version of PHP makes your script *dependant* on that version of PHP. This is how it works. If we do allow the conditional dependency then the package should use PHP_Compat::loadFunction() or PHP_Compat::loadVersion(). It should not include the file itself. > > What about when you want to use the new signature of an existing > function, for instance file_get_contents() PHP5's new parameters? Then you *have* to have a dependency on the version of PHP that supplies it, period. There's no way of altering a vuilt-in function short of an extension and extensions cannot be relied upon. If you want to use a new feature in a function but don't want a dep on that version of PHP you *can* put a condition around your call to use your own version or PHP_Compat's version (assuming they get the function name thing fixed) but again this would mean a conditional dependency. Adding conditions around function calls is mostly a hack...you *could* define your own version of the function conditionally based on the PHP version but this is something that can get real hard to support real quick and IMHO is uneeded complexity. Make your package dep on the PHP version it needs for the features you want. If the user wants to run on an older version they can figure out what to do to fix it. > > I don't think it is reasonable to ask the end user to include the > PHP_Compat files in their script, they may not know exactly when that > function will be required, or it could be troublesome to update 100+ > files of an existing web site. If it's a matter of a missing function they can easily use PHP_CompatInfo to figure out what functions to include. If it's a signiature/feature change then they will need to upgrade their PHP. > > What is reasonable IMO is to ask the end user to *install* the > PHP_Compat package if needed and let the PEAR package itself load it on > its own time. This is the only way to avoid breaking BC of existing apps. Assuming a conditional dependency works, yes. If it's a note on the package web page, though, this is not ok. And, again, IMHO, using PHP_Compat to fill in missing things is a hack and really should not be done in packages themselves. > > This information ought to be clarified and put into PEAR's developer guide. > I agree. Perhaps we need a proposal once this discussion dies down. -- Justin Patrin