Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83811 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2326 invoked from network); 25 Feb 2015 17:52:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Feb 2015 17:52:22 -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 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:53292] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F9/72-20665-3DB0EE45 for ; Wed, 25 Feb 2015 12:52:22 -0500 Received: (qmail 7871 invoked by uid 89); 25 Feb 2015 17:52:17 -0000 Received: by simscan 1.3.1 ppid: 7863, pid: 7867, t: 0.0811s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 25 Feb 2015 17:52:17 -0000 Message-ID: <54EE0BD1.2040209@lsces.co.uk> Date: Wed, 25 Feb 2015 17:52:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com> <8250289916f5128b5bc1a114428d374e@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC From: lester@lsces.co.uk (Lester Caine) On 25/02/15 15:31, Pierre Joye wrote: > With the other RFC, which changes the casting modes, I wish everyone > good luck. I may be wrong, can happen ;), but we simply do not know > and will not know before 7.0.0 is out. Good luck to change them again > to "adapt and tweak", and good luck to the apps developers to adapt > their apps with plenty of patch versions checks. This is the reason #2 > why I am against your RFC, the #1 being the total lack of actual non > magic casting (read: strict), optionally enabled. Like you I don't see the point of the casting changes but similarly I don't see why we have to have strict mode bolted in to everybodys systems as well. Both RFC's seem to be trying to push the bitter pill through with the main payload ... Scalar Type Hinting. There doses seem to be a general assumption that everybody wants STH therefore it has to be included and I am sure that that simple question would get a substantial majority. As with other 'hints' there is a difference in opinion on just what 'everybody' wants. My objection is perhaps to all targeting an different rule sets, none of which actually do the whole job, and now that I am starting to get into just how the code works, I think I can see openings for hook points where just how a particular style of working can be accommodated. Just as the problem with case-sensitive core, if the right 'filter' can be made selectable we can all have what we want. Yes it will result in confusion over what runs where, but equally we can tailor hinting to match a particular set of rules rather than having to live with some other persons preference such as the 'new' casting rules ... -- 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