Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61172 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15868 invoked from network); 12 Jul 2012 16:46:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jul 2012 16:46:47 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.153 smtp153.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.153] ([67.192.241.153:42048] helo=smtp153.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EA/C0-11045-57FFEFF4 for ; Thu, 12 Jul 2012 12:46:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id E569058243; Thu, 12 Jul 2012 12:46:42 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 78E0358441; Thu, 12 Jul 2012 12:46:42 -0400 (EDT) Message-ID: <4FFEFF71.2060202@sugarcrm.com> Date: Thu, 12 Jul 2012 09:46:41 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rasmus Lerdorf CC: Anthony Ferrara , "internals@lists.php.net" References: <4FFEFBB3.7090507@sugarcrm.com> <4FFEFD81.6020404@lerdorf.com> In-Reply-To: <4FFEFD81.6020404@lerdorf.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Iterable Type Hint From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > For non-interchangeable types it is already strict by definition. I > don't see a problem with type hints that make life easier on both the > caller (by generating better error messages) and the callee (by having > to write less boilerplate type verification code). It doesn't make the life of the caller easier. On the contrary, it makes each call into a minefield - will it blow up with a system-level error when you call it? Added bonus of this one is that there's no sure way to check for it - at least for callable we had is_callable, here we just have to add boilerplate code for every call. And good luck making them handle it in an unified way - since it's not library code, then probably will do each different thing, and about 50% of places will forget it or not know downstream inserted this surprise into the execution stream. > You may have a point on the ad-hoc nature of it and that we need to do > it once and for all in a more organized fashion, but the basic premise > looks ok to me. I think the basic premise (PHP needs more strict typing that it is completely unable to properly handle and that leads to runtime errors that had no choice but blow up the whole app) is wrong, but ad-hoc implementation of it by just dragging random pieces into the type system is even more wrong. Note that no other dynamic language is doing such things. I wonder why. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227