Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75553 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2174 invoked from network); 15 Jul 2014 17:32:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jul 2014 17:32:42 -0000 Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.200 imap1-2.ox.privateemail.com Received: from [192.64.116.200] ([192.64.116.200:33371] helo=imap1-2.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 37/14-15121-8B565C35 for ; Tue, 15 Jul 2014 13:32:41 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id 567D5B00081; Tue, 15 Jul 2014 13:32:38 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap1.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap1.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vecLHRjR2TtI; Tue, 15 Jul 2014 13:32:38 -0400 (EDT) Received: from [192.168.0.15] (unknown [90.210.122.167]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 683BAB0007B; Tue, 15 Jul 2014 13:32:36 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) In-Reply-To: <53C563B3.6060905@gmail.com> Date: Tue, 15 Jul 2014 18:32:32 +0100 Cc: Stas Malyshev , "internals@lists.php.net" Content-Transfer-Encoding: quoted-printable Message-ID: <5F04F637-5C83-4A3D-9186-D1AAFF9D4547@ajf.me> References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me> <05CE2216-C5D9-4937-9F2E-AA1407284D9F@ajf.me> <53C460DF.5040304@sugarcrm.com> <53C53A96.2040303@gmail.com> <53C55342.1010207@sugarcrm.com> <53C563B3.6060905@gmail.com> To: Rowan Collins X-Mailer: Apple Mail (2.1878.6) Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) From: ajf@ajf.me (Andrea Faulds) On 15 Jul 2014, at 18:24, Rowan Collins wrote: > Stas Malyshev wrote (on 15/07/2014): >> IMO, having consistent rules is much more, orders of magnitude more >> important than serving any particular use case >=20 > We are adding a new feature to a language which is already = inconsistent. We can only make it consistent with one part of the = language by making it inconsistent with another. >=20 > If we take consistency as such a priority that we create a feature = that is not actually useful, we will have wasted our effort, and made = the language worse, not better. Saying "who cares if its useful, as long = as it matches some other part of the language" is a very poor argument = IMO. >=20 > That's an extreme, and I'm not saying anyone is saying precisely that, = but I am getting rather weary of the back-and-forth over what is = "consistent", rather than thinking about what we want to achieve, and = what is the best way to achieve that. I=92d argue it=92s better to do the right thing here, which is easier, = and then do the right thing in the other place later, which is harder, = than it is to do the wrong thing now because the other place also does = the wrong thing. Having saner implicit casting for scalar type hints = will be easier than changing the behaviour of zend_parse_parameters. >> What you want is strict typing then. >=20 > No, I want to introduce the notion of a "lossless cast", allowing = things like (int)'123' to be valid. This distinction has been explained = many times. > >> And if() working the same way - >> after all, if function can be unaware of the flag, if() is definitely >> unaware of it. >=20 > Not necessarily. An if() statement is clearly and unambiguously = working with boolean values. Anyone looking at if( $foo & BIT_FLAG ) can = know, based on basic knowledge of the language, that an implicit cast is = taking place. >=20 > Someone looking at my_super_function( $foo & BIT_FLAG ) cannot know = whether that parameter is being interpreted as a boolean or is actually = being measured against that same BIT_FLAG (or some other integer = operation) without consulting the source code (or, at least, trusting = the documentation). >=20 >> I am not among them. If you want >> to enforce code style, we already have tools for that, but I don't = think >> this particular one should be in the language. >=20 > The logical conclusion from that is not to have type hints at all. So = far, that is in fact the only consensus the PHP community has ever = reached - not to have scalar type hints. (I don't mean that you = necessarily hold that position, but it is the logical conclusion of that = particular line of reasoning.) >=20 > Regards, > Rowan Collins > --=20 > [IMSoP] >=20 > --=20 > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >=20 I, myself, generally agree with all this, though I=92m not sure quite = whether Anthony does at the moment. -- Andrea Faulds http://ajf.me/