Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:44713 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84971 invoked from network); 5 Jul 2009 08:51:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jul 2009 08:51:26 -0000 Authentication-Results: pb1.pair.com smtp.mail=addw@phcomp.co.uk; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=addw@phcomp.co.uk; sender-id=permerror Received-SPF: pass (pb1.pair.com: domain phcomp.co.uk designates 213.152.38.186 as permitted sender) X-PHP-List-Original-Sender: addw@phcomp.co.uk X-Host-Fingerprint: 213.152.38.186 freshmint.phcomp.co.uk Linux 2.6 Received: from [213.152.38.186] ([213.152.38.186:61878] helo=mint.phcomp.co.uk) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5F/86-50478-C89605A4 for ; Sun, 05 Jul 2009 04:51:25 -0400 Received: from addw by mint.phcomp.co.uk with local (Exim 4.63) (envelope-from ) id 1MNNRI-0002DX-AS; Sun, 05 Jul 2009 09:51:12 +0100 Date: Sun, 5 Jul 2009 09:51:12 +0100 To: Zeev Suraski Cc: Ilia Alshanetsky , Tom Boutell , "internals@lists.php.net" Message-ID: <20090705085112.GW4355@mint.phcomp.co.uk> References: <20090701171533.GI4355@mint.phcomp.co.uk> <7.0.1.0.2.20090705112530.16320530@zend.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20090705112530.16320530@zend.com> User-Agent: Mutt/1.4.2.2i Organization: Parliament Hill Computers Ltd Subject: Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3 From: addw@phcomp.co.uk (Alain Williams) On Sun, Jul 05, 2009 at 11:30:28AM +0300, Zeev Suraski wrote: > I think there's a more fundamental flaw here than just pointing to > 'numeric' as an alternative. The internal IS_* setting is > meaningless for countless pieces of data floating around in PHP, > arguably far more than the ones for which it truly represents the > 'semantic' type. Continuing what Stas said, it's no coincidence our > internal functions transparently translate arguments to the required > types (except for the rare cases where it's not possible). > > The other course of action is to change the implementation so that it > behaves like the one for internal functions - with emphasis on > conversion instead of validation of IS_*. We can consider being more > strict - and error-out on non-numeric strings instead of producing > 0; If we were to start from scratch today, we'd probably do the same > for internal functions. Encouraging the equivalent of strict is_*() Maybe that is something to consider: PHP 6: warn on non-numeric strings, dependent on something in php.ini PHP 7: error on non-numeric strings If someone has some code that goes: $six = 3 + 'three'; then is isn't doing what they intend, so an error would be helpful. The question is one of transition - breaking code that doesn't do input validation, hence for a transition to help the better programmers. As for the cr*p programmers - well their code was broken anyway. > checks is very inconsistent with both our entire internal functions > library, as well as the common behavior of PHP. It doesn't come to > say that it's not useful in some cases - but for these, using is_*() > should be a suitable. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include