Re: Re: RFC::Error Handling Guidelines for PHP5 packages

On Tue, 24 Aug 2004 18:37:28 +0200 (CEST), Stig S. Bakken <stig@yahoo-inc.com> wrote: > On Tue, 24 Aug 2004, Alexey Borzov wrote: > > > Hi, > > > > Davey wrote: > > > As I said, this is my final attempt to inject sanity into this... > > > although I may contact the PEAR Group on this matter, only they can > > > really interject now that the voting process has started. > > > > If PEAR group turns down the community approved proposal after failing > > to participate in community process in any way, this will have very > > unfortunate consequences. > > I have just "returned" from a period where I had absolutely no time for > PHP/PEAR, to see that PEAR seems to have absolutely no direction wrt. to > exceptions and PHP 5 migration (I have missed out a few thousand emails > mind you). > You say it has no direction with regard to exceptions, but this RFC was created for PEAR to have one. > This proposal does not go into the nitty-gritty of the real error > handling-related issue PEAR is facing: how to migrate to exceptions > without too much pain for developers and users? This is nitty-gritty, but it's not what the RFC is about. More below. > > Yes, this is beyond the scope of this RFC, so then my claim is that this > RFC is premature. > > I've suggested to Sergio that we can extend it to include a migration plan > _and_ these guidelines, pull this RFC back and then publish a new and > comprehensive one. My impression (feel free to correct me if I've > misunderstood you Sergio) is that he would rather just push it through now > since it's in the pipeline and he (and probably others) have been working > on it for so long. I heartily disagree here. Before you can have a migration plan, you have to know what you're migrating *to*. This RFC defines how error handling is supposed to work in PHP5. Once we decide how PHP5-only error handling is supposed to work, we can then start on a migration plan. Doing them both in parallel in the same RFC: 1) is lots more work as a single change in the error handling part can mean lots of rewriting in the migration. 2) causes PHP4 and PHP5 to be included in the same context when what we're talking about here is a completely new way of handling errors for PHP5-only packages. We need to define what we want our PHP5 error handling mechanism to be without regard to PHP4 or how it is currently done. Why? So that we don't end up with a kludgy mess of spaghetti code. We need to define this from the ground up, then figure out how it affects current PHP4 only packages. We will all be happier in the future when we have one single easy to use error handling scheme. > > If the RFC is premature, it doesn't help how long it's been in the pipe, > it's still premature. Does the fact that I've been away for several > months force me to shut up when I see that a bad move is about to be made? > I've learnt this the hard way: when PEAR was in its infancy, there were > bi-monthly "what is PEAR?" flamewars. The main reason for this was that I > had not done a good enough job communicating my ideas. But I did > communicate parts of it, enough for people to get part of the picture and > misunderstand, and then you have it going. Don't do that mistake. > > I'm seeing the same patterns here and I'm pretty sure the same thing will > happen with error handling if we're not careful. If this RFC goes out > there, people are going to think this is the rule book for dealing with > PEAR errors in PHP 5. It's bad enough that they have to rewrite their > code once, if not several times because they keep getting new information > about the "latest and greatest" way of doing error handling. Sergio is > probably pissed off because I'm trying to make him drop/freeze something > he has invested a lot of time in, but that is nothing compared to the > collective amount of time all of us would have to spend reimplementing > error handling in some package for the Nth time (to make it compatible > with another package that just did the same thing). > > There is an RFC that needs to come before this one, and it is the contents > of that pear-dev needs to focus on: > > * how to maintain compatibility with existing packages until then, both > for package maintainers and users This should happen after we decide on the new scheme, otherwise, what are you trying to be compatible with? > > * bloat control: PEAR_Error, PEAR_Exception and PEAR_ErrorStack total > over 2000 lines of code, error handling must not become even more > cumbersome than it is today with PEAR_Error This is what this RFC is doing. Start from the ground up on a new scheme. Once code is migrated to PHP5, we'll have a clean error handlign code-base. > > * the end goal, when PHP 5 is the primary development platform Again, the end goal is this RFC. > > I suggest we start there, but in a new thread please. > > - Stig > -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--