Re: Re: PEAR_Exception in CVS

On Sat, 03 Jul 2004 21:13:23 -0400, Greg Beaver <cellog@php.net> wrote: > Hans_l wrote: > > > This is PHP5 only. I think that's the way to go because nothing PHP4 is > > gonna run in E_STRICT, hence no PHP5 PEAR package can work with any > > PHP4-friendly libraries. > > Apologies in advance for the long message, I would like to explain a > basic difference viewpoint that I feel will get in the way of > development if it isn't worked out. I've been proposing a compatibility layer between the two for a while now that would allos PHP5 users to also use old PHP4 code *and* get Exceptions, but no one has been listening to me. All I get is PHP5 zealots saying that E_STRICT is the only way to go, that everyone should upgrade *now*, and that they don't care about the old code and compatibility. Please, anyone who supports this, let the list know. > > Summary: > > we should require complete E_STRICT compliance except for php5 keywords > for php4 packages that will work in php4 and php5, but there must be a > transition between php4 and php5, based on API compliance. > > Long version: > > I think you're approaching this from a backwards perspective of how I > see that things will happen. There is a HUGE base of PHP4-based > applications, and many of them work really well. Even if you or I > disagree with the masses about the quality, there are lots of people who > use these pear script things in custom scripts based on the current PEAR > API. I don't know about you, but I don't imagine that everyone will be > as zealous about rewriting their scripts simply because the syntax for > error handling has changed. > > We need a time period that allows packages that work in both PHP4 and > PHP5. E_ALL would be the standard for these packages, so that complex > applications can easily move to php5 after everything has been fully tested. > > The best thing about Tomas's script (and better than PEAR_ErrorStack > alone) is that PEAR::raiseError will still work - the API is the same > for both PHP4 and PHP5. There was no facility for doing > warnings/notices in PEAR, and so PEAR_ErrorStack does not break API. > PEAR_ErrorStack is php5-compatible, even if it isn't E_STRICT. Perhaps > I could provide a version with all "var" replaced with "protected" and > then it would :). > > There will be other more significant changes in the move to php5, and we > should limit the number of changes that users must process at one time > to aid in debugging. > > Don't forget that people are not going to jump to php5 simply because a > few geeks like me say it's great :). It must be proven to be great, and > complex packages/applications like DB will not transition to php5 > overnight, there will be a period where php4 will still be supported. > > Some of the application will only need to be modified rather than > redesigned to work in PHP5, but what if the similarities between PHP4 > and PHP5 could be used to make this transition smooth? Why require a > complete rewrite of a simple application, when in most cases, changing a > few "var" statements to "public" or "private" is all that will be > needed > to comply with E_STRICT? Once the transition occurs, and php4-ites run > their applications in php5, php5-only scripts may be released with impunity. > > For this reason, if we can encapsulate the php5-specific error stuff > (exceptions) and provide an API to error handling that both php4 and > php5 packages/applications can use, it will be far more intelligent. > Any other method will simply force a serious stability downgrade for > months. Or worse, a "stable" package that has hidden bugs. > > sure, php5-only packages need to be E_STRICT to help make E_STRICT > possible, but end-user applications need not be E_STRICT until they have > had the time to run under php5 and understand both the problems and > benefits. > > Greg > > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--