Hello Ilia,
Monday, May 15, 2006, 3:23:18 PM, you wrote:
> I suggest that we add E_STRICT now, but not include E_STRICT into
> E_ALL,
We added E_STRICT in what 5.0 or or 5.1? Guess i checked it:
[EMAIL PROTECTED] /usr/src/php-cvs $ cvs annotate Zend/zend_errors.h|grep
E_STRICT
Annotations for Zend/zend_errors.h
***************
1.15 (andi 18-Nov-03): #define E_STRICT (1<<11L)
1.22 (dmitry 16-Mar-06): #define E_ALL (E_ERROR | E_WARNING | E_PARSE
| E_N
[EMAIL PROTECTED] /usr/src/php-cvs $ cvs log Zend/zend_errors.h|grep php_5_0_0b
php_5_0_0b4: 1.17
php_5_0_0b4RC1: 1.17
php_5_0_0b3: 1.16
php_5_0_0b3RC2: 1.16
php_5_0_0b3RC1: 1.16
php_5_0_0b2: 1.14
php_5_0_0b2RC1: 1.14
php_5_0_0b1: 1.14
[EMAIL PROTECTED] /usr/src/php-cvs $
> so people who are not using E_STRICT error reporting level
> don't have their applications start spewing strict messages.
> We cannot force people to change their code, all we can reasonably do
> is provide notification mechanism, for those who do.
Yes and that is E_STRICT. And if we continue the way we do now we will have
not only unicode problems when people upgrade to 6...
> On 15-May-06, at 9:16 AM, Derick Rethans wrote:
>> On Mon, 15 May 2006, Ilia Alshanetsky wrote:
>>
>>> My opinion is that if we intend to make something stop working
>>> (give fatal
>>> error) in future releases we need to provide some form of notice
>>> be it
>>> E_STRICT or E_NOTICE to our users now, so they can anticipate the
>>> change. As
>>> far as inclusion of E_STRICT into E_ALL, I think this is a good
>>> idea, but is
>>> probably premature for the 5.2 release.
>>
>> Then when do you suggest we add it (before 6.0)?
>>
>> regards,
>> Derick
>>
> Ilia Alshanetsky
> Advanced Internet Designs Inc.
> [EMAIL PROTECTED]
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
