RE: [PEAR-DEV] BC breakage results

From: Date: Fri, 19 Sep 2003 13:18:44 +0000
Subject: RE: [PEAR-DEV] BC breakage results
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-21768@lists.php.net to get a copy of this message
> -----Original Message----- > From: Bertrand Mansion [mailto:bmansion@mamasam.com] > Sent: Friday, September 19, 2003 9:04 AM > To: Rob Hutton; Alexey Borzov; Jan Schneider > Cc: pear-dev@lists.php.net > Subject: Re: [PEAR-DEV] BC breakage results > > Just as a sidenote : > > There are multiple levels of errors available : warnings, notices... > They should be treated differently by the user. Agreed, unless you have something that should never return a pear error and now does. If the original method definition specified a return type of mixed or PEARError, then no problem. But the return type of a function should not change within a minor release. Isn't there some warning that gets kicked if you are using depriciated functions anyway? What about a tool available to developers to read through code and show them where they are using functions marked as depreciated. Does PHPEdit or Zend already do this? > > For example, AFAIR, in PHP if you use setlocale('LC_ALL', 'fr_FR') it will > issue a warning telling you setlocale now expects the user to use > the locale > constants (LC_ALL instead of 'LC_ALL'). Still, the function does the job. > Which is fine as long as the return type is/has always been mixed or PEARError... > > Now, using a some error log function as PEAR Error handler, it makes it > easier to find the faulty piece of code. The error log function can be > prepended using auto_prepend for a week or two. Maybe that's not the best > solution... > IMHO, nagging the developer with run time warnings does not help them find problems, it encourages them to fix them though. I have issue with the premise that because you break BC, that is somehow the problem of the people that depend on your class though... Thanks, Rob

« previous php.pear.dev (#21768) next »