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

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. 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). 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? What about when you want to use the new signature of an existing function, for instance file_get_contents() PHP5's new parameters? 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. 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. This information ought to be clarified and put into PEAR's developer guide. -Philippe