Re: Call for Review: RFC for Error Handling in PHP5 packages

I might have not expressed myself correctly. My opinion is that coding error handling in a BC fashion means coding using the maximum common denominator of both approaches, effectively dropping deferral of error checking and recovery, and introducing extra effort in development: http://wiki.ciaweb.net/yawiki/?area=PEAR_Dev&page=RfcExceptionUse#toc15 http://wiki.ciaweb.net/yawiki/?area=PEAR_Dev&page=RfcExceptionUse#toc16 Packages requiring PHP5 will be doing so for the new features. New PHP5 features, if they are to be fully used, require a break in BC. Therefore, it's useless running the extra mile to avoid breaking BC in error handling, as it'll be broken by the usage of Interfaces or Iterators or any of the other new features. As for the 2 repositories, that's an option I like a lot, because it allows for launching the discussion about redesigning packages around interfaces, tightening a nudge the extremely loose coupling of PEAR packages. However, it has already been discussed and the conclusion was that merely upgrading versions and requiring PHP5 would be enough (DB becomes DB2, XML_RPC becomes XML_RPC2, etc...). Feel free to propose the 2 repository option -- you have a supporter here. Cheers, Sérgio P.S. The original message was crossposted to pear-core, so I'm crossposting one last time. Future replies will go to pear-dev only. Greg Beaver wrote:

Moot point - PEAR/ErrorStack.php is php4, PEAR/ErrorStack5.php is php5 E_STRICT (class name is the same) and php5-only packages could use that. Or, users could simply delete PEAR/ErrorStack.php and rename ErrorStack5.php to ErrorStack.php, unless the PEAR installer does this automatically (which it might soon) All debating aside, the basic difference that MUST be resolved is: 1) people who clamor for E_STRICT and say BC is impossible 2) people who want BC to be possible so that migration to PHP5-only E_STRICT packages occurs. For those who are in camp (1), there is *only 1 real solution* which was proposed by Heino Gehlsen. We must have 2 separate repositories in different channels, one for PEAR php4 (and possibly php4/php5) packages, and one for PEAR php5-only packages. This will allow duplicate code that differs only in 1) error handling 2) var vs. public/protected/private as in: pear::DB would return PEAR_Error, or use PEAR_ErrorStack or whatever pear5::DB would throw exceptions and use some to-be-determined php5-only warning system for any warnings. BOTH would be "class DB" in DB.php For those who are in camp (2), there is also only 1 real solution, which is to force all packages to have a php dependency on php < 5.0 and deprecate themselves in favor of a pear5 package, or to just plain deprecate them altogether and keep legacy releases, so that it is clear that php4 is deprecated, although still fully supported. *ANY* other solution will cause endless, and much less fruitful bickering. The technical hurdles involved are tremendous - pearweb cannot be rewritten to handle channels without some serious kludging. Only a from-scratch channel server implementation will make the transition smooth. Before the PEAR project website is able and ready to support multiple channels, any solution for camp 1 is physically impossible. Those who are clamoring for E_STRICT-only php5 packages would do much more good if they were to contribute coding ideas to pearweb to implement channels rather than contribute conversation on how php4 packages aren't E_STRICT-compatible. This includes ideas on how to minimally alter the existing database, perhaps to split the database up, or other possibilities that are more practical (should they exist). Greg

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc