Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65261
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <51069A20.3050808@lsces.co.uk>
References: <op.wq746rv5idpuyk@damnation.nl.lo.geleia.net>
	<op.wrmidlpiidpuyk@damnation.nl.lo.geleia.net>
	<debcd9bb-79f3-4b2c-aa66-9461018959c9@email.android.com>
	<CAH-PCH7PO9i_vRqG9ztpP6aqkKM13=qo-TPBbA21+2sQ3mcpaw@mail.gmail.com>
	<51069A20.3050808@lsces.co.uk>
Date: Mon, 28 Jan 2013 16:48:04 +0100
Message-ID: <CAH-PCH430W4b0tDaS0R6wJbn553v=PgpqLV2VrSoxNuJhv-WCg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae93411e7e538e204d45b33b0
Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context
From: tyra3l@gmail.com (Ferenc Kovacs)

--14dae93411e7e538e204d45b33b0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 28, 2013 at 4:32 PM, Lester Caine <lester@lsces.co.uk> wrote:

> Ferenc Kovacs wrote:
>
>> >But this is a core php feature, for anyone who does not use traits.... =
We
>>> >use this quite a bit, it may not be for purists, but it has worked
>>> >perfectly for years. This is getting a bit silly, change for change
>>> sake....
>>> >
>>>
>> I've found this to be a huge wtf when you bump into, and already reporte=
d
>> by E_STRICT, so I was sold to the arguments made in the RFC.
>>
>
> I think that this is the point here ...
> In order for legacy code to even work, E_STRICT has to be disabled, so on=
e
> does not see any problem.


Please Lester, could you stop pretending that E_STRICT errors will crash
your application and kill all the kittens?
There are a bunch of people (myself included) who tries to write E_STRICT
free code so that our application is fast and bugfree?
Yes, there are people who ignore E_STRICT and E_DEPRECATED and I agree that
having a zillion of those in the PEAR packages is a wrong thing.
But currently it is the way to remove a feature: deprecate it both in the
code and the manual, advertise in the release announcement, and remove it
in the next version, hence people who are interested in keeping up with the
changes will know what do they need to check and change.


> That is the whole point of the switch? There is no requirement to test
> code with the switch on, the wtf comes when something that is 'protected'
> by E_STRICT is later removed!


E_STRICT was introduced in 5.0 E_DEPRECATED was introduced in 5.3, E_STRICT
was used for things that we use E_DEPRECATED now, but E_STRICT can be used
stuff other than deprecating features (like suggesting better alternatives:
http://lxr.php.net/xref/PHP_5_5/ext/date/php_date.c#1493 )



> This was one of the major rework areas on my own code and I can TOTALLY
> understand people taking the ADVISED ROUTE of switching E_STRICT off as a=
n
> alternative solution.


What do you mean by ADVISED ROUTE?
I don't think we officially advised anybody for ignoring
errors/warnings/etc.
Maybe you mean that somebody from the php project advised you to ignore the
E_STRICT messages in a 3rd party library that you are using and not wanting
to clean up yourself?


> NOW the question is, what is the point of E_STRICT if it can't be avoided
> anyway?


http://php.net/manual/en/errorfunc.constants.php
"Enable to have PHP suggest changes to your code which will ensure the best
interoperability and forward compatibility of your code."


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--14dae93411e7e538e204d45b33b0--