Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:44650 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43322 invoked from network); 2 Jul 2009 13:44:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Jul 2009 13:44:28 -0000 Authentication-Results: pb1.pair.com header.from=robert@interjinn.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=robert@interjinn.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain interjinn.com from 66.11.173.122 cause and error) X-PHP-List-Original-Sender: robert@interjinn.com X-Host-Fingerprint: 66.11.173.122 unknown Received: from [66.11.173.122] ([66.11.173.122:50917] helo=interjinn.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B0/E5-16153-CB9BC4A4 for ; Thu, 02 Jul 2009 09:44:28 -0400 Received: by interjinn.com (Postfix, from userid 5001) id 6A52338C113; Thu, 2 Jul 2009 09:44:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gruknuk.suds X-Spam-Level: X-Spam-Status: No, score=-4.4 required=7.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 Received: from [192.168.1.3] (blobbie [192.168.1.3]) by interjinn.com (Postfix) with ESMTPS id EA53438C043; Thu, 2 Jul 2009 09:44:16 -0400 (EDT) Message-ID: <4A4CB9FC.2030909@interjinn.com> Date: Thu, 02 Jul 2009 09:45:32 -0400 Organization: InterJinn User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ilia Alshanetsky CC: Lukas Kahwe Smith , Paul Biggar , PHP Internals , Derick Rethans , Stanislav Malyshev , Hannes Magnusson References: <4A4CB074.1010000@interjinn.com> <4A4CB4BC.90101@interjinn.com> <8FC81E2C-8E83-41F8-9C89-B3E60CCFBB3A@ilia.ws> In-Reply-To: <8FC81E2C-8E83-41F8-9C89-B3E60CCFBB3A@ilia.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Flexible type hinting From: robert@interjinn.com (Robert Cummings) Ilia Alshanetsky wrote: > On 2-Jul-09, at 9:23 AM, Robert Cummings wrote: > >> Ilia Alshanetsky wrote: >>> On 2-Jul-09, at 9:04 AM, Robert Cummings wrote: >>>> Ilia Alshanetsky wrote: >>>> >>>>> Paul's proposal is some part does not make sense because it >>>>> allows weak type hinting, which should not be used if you need >>>>> type hinting. The whole idea about type hinting is definition >>>>> of strict interfaces, not loosely based one. That's just my >>>>> opinion, which admittedly I feel fairly strongly about. >>>> It's a hint, not enforcement. IMHO hinting about something is not >>>> strict, it's a suggestion. >>> Have you using existing array or class type hinting? >> I have, and IMHO it makes more sense for strict checking (though not >> too strict since super classes make sense) when objects are being >> passed. But in the case of primitive datatypes where coercion >> between types is well established and understood, I think it should >> be a warning. PHP knows how to convert the string '1' to integer. It >> knows how to convert 0 to boolean false. These were established many >> years ago. On the other hand PHP does not know how to coerce (in a >> sensible way) class FreakyDeaky to class GobbletyGoot. > > It is not about what PHP can convert, in the past and if you use old > function parameter parsing api PHP will even convert arrays to > strings. Its about delivering to the function/method exactly what it > wants and not a close facsimile thereof. That's why I said, instead of E_RECOVERABLE it should be an E_WARNING with type coercion to what the hint requested. The function gets what it wants, and the developer gets a warning that it wasn't quite what it expected. Run time code doesn't just die because I've upgraded an application and missed a single API call update to comply with primitive type hinting. That's annoying in a production environment, and since it's run-time fail, it's not necessarily easy to catch all the issues. There *will* be production systems dying due to missed updates. There's the suggestion to capture the E_RECOVERABLE error, but that's putting the onus on developers and non-developers installing applications to have this in place, and due to the run-time nature of the problem, *everyone* would be better off putting it in place, just in case their production system goes down. Since 99% of coercions of primitive types are fine, I don't see why the majority must suffer the problem when the minority will be perfectly served by an E_WARNING to correct their code. You mentioned in your environment you've been using this for a while now and found problems otherwise very difficult to find. These same problems would also have been detected with an E_WARNING with the added value of the application not dying (or do you already have that E_RECOVERABLE handler in place). Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP