Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:77209 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13053 invoked from network); 15 Sep 2014 05:45:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Sep 2014 05:45:06 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 173.203.6.155 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 173.203.6.155 smtp155.ord.emailsrvr.com Linux 2.6 Received: from [173.203.6.155] ([173.203.6.155:32936] helo=smtp155.ord.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 27/06-64534-0EC76145 for ; Mon, 15 Sep 2014 01:45:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 1A0B8180091; Mon, 15 Sep 2014 01:45:01 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.ord1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id AD882180089; Mon, 15 Sep 2014 01:45:00 -0400 (EDT) X-Sender-Id: smalyshev@sugarcrm.com Received: from Stass-MacBook-Pro.local (c-73-53-124-150.hsd1.wa.comcast.net [73.53.124.150]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.2.10); Mon, 15 Sep 2014 05:45:01 GMT Message-ID: <54167CDC.9040801@sugarcrm.com> Date: Sun, 14 Sep 2014 22:45:00 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Pierre Joye , Rowan Collins CC: PHP internals References: <6893A97A-EC4C-4124-B804-96E2A26B953F@ajf.me> <20140914000718.GB14312@phcomp.co.uk> <3177B936-50C1-4E5D-8687-FD235C72B411@ajf.me> <54153692.7050500@sugarcrm.com> <9CE963B0-E624-4267-BC2A-0F8D1F985DAE@ajf.me> <6f2236e18c61d30b247e1c6bb2de10f1@mail.gmail.com> <8556C1E7-EDF3-47E2-9DA0-C9AB63DE56E6@ajf.me> <6E402FE8-119A-4BBB-B652-97A0DBEC8BC9@ajf.me> <5415DC76.7070105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > This is exactly the issue we are battling here. One side wants to be > consistent with inconsistencies (and tbh quite confusing) while the other > side wants to allow userland implemented APIs to actually be consistent. It's not the issue here. Nobody wants 100% of functions to do the same, and everybody knows there will be exceptions when some functions can not accept all values covered by type, or can accept multiple types but only in certain situations, etc. etc. What we want is to have one set of rules (yes, again, not covering 100% of functions, both user and internal, but covering most of them in the same way) instead of two different sets of rules. > I am not judging any of these sides but we are heading to a status quo > here, for no good reason. We all know that this is a feature desired by a > very large of our users. Let not block it. Nobody is "blocking it". What we're talking about is not making inconsistent arbitrary implementation that prevents us from making a consistent one (since if we introduce two inconsistent sets of rules, we won't be able to make it one consistent set of rules until the next major at least). In my opinion, it is better not to have it until it's ready than have it in a broken way just because "users want it" so we have no time to do it right. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/