RE: [PEAR-DEV] BC breakage results
| From: | Rob Hutton | 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