Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65257 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23058 invoked from network); 28 Jan 2013 15:32:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Jan 2013 15:32:53 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.132 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 213.123.20.132 c2bthomr14.btconnect.com Received: from [213.123.20.132] ([213.123.20.132:26739] helo=mail.btconnect.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 20/4E-28517-32A96015 for ; Mon, 28 Jan 2013 10:32:52 -0500 Received: from host81-138-11-136.in-addr.btopenworld.com (EHLO _10.0.0.5_) ([81.138.11.136]) by c2bthomr14.btconnect.com with ESMTP id KOJ95386; Mon, 28 Jan 2013 15:32:48 +0000 (GMT) Message-ID: <51069A20.3050808@lsces.co.uk> Date: Mon, 28 Jan 2013 15:32:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14 MIME-Version: 1.0 To: PHP Internals References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.51069A20.0010, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2013.1.27.63334:17:7.944, ip=81.138.11.136, rules=__MOZILLA_MSGID, __HAS_MSGID, __SANE_MSGID, __HAS_FROM, __USER_AGENT, __MOZILLA_USER_AGENT, __MIME_VERSION, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __CT, __CT_TEXT_PLAIN, __CTE, __ANY_URI, __URI_NO_MAILTO, __URI_NO_WWW, __C230066_P3_4, __CP_URI_IN_BODY, BODY_ENDS_IN_URL, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1200_1299, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.51069A20.006F:SCFSTAT14830815,ss=1,re=-4.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context From: lester@lsces.co.uk (Lester Caine) 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 reported > 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 one does not see any problem. 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! 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 an alternative solution. NOW the question is, what is the point of E_STRICT if it can't be avoided anyway? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk