Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61173 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17566 invoked from network); 12 Jul 2012 17:01:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jul 2012 17:01:18 -0000 Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.216.49 mail-qa0-f49.google.com Received: from [209.85.216.49] ([209.85.216.49:57985] helo=mail-qa0-f49.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7F/11-11045-ED20FFF4 for ; Thu, 12 Jul 2012 13:01:18 -0400 Received: by qabj40 with SMTP id j40so2057400qab.8 for ; Thu, 12 Jul 2012 10:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WR8nhImANWdO+9AGjrmpPXau+DHZgMzcep2D/VjYDEk=; b=w+8S3tAuO5M5tg/Nc2upvklzn2lfNGvlehqTMd8x7eyco1xe9fnCKuW8hLHX5gzJPB RS6xsRu5jBv624/JWMZrsNNHrdgNY7f1h4ADC7Sb1/pO5u2cPMceBDzbHVcMxaTSr/rm w7pFkWViw4p++76gFPuhTbM2VbIvgzeKigcedc6TUjDh6LCYI8tLTFHkqIylbNmiC8Wg bVMqu3mSYMSy29OWyDcGMxiD58/W+3b8IUj6uspZ9d+BS43Rl9n2f/iwHoDFt/c3mRgB QbSOMvkQwJgzY1z/wVX4Ic+KhmRcxDc5pTy2NKOHpEXYQLvJbQzLRNweFGN9wITrjGGC gchw== MIME-Version: 1.0 Received: by 10.229.135.129 with SMTP id n1mr28107314qct.32.1342112475664; Thu, 12 Jul 2012 10:01:15 -0700 (PDT) Received: by 10.229.232.11 with HTTP; Thu, 12 Jul 2012 10:01:15 -0700 (PDT) In-Reply-To: <4FFEFF71.2060202@sugarcrm.com> References: <4FFEFBB3.7090507@sugarcrm.com> <4FFEFD81.6020404@lerdorf.com> <4FFEFF71.2060202@sugarcrm.com> Date: Thu, 12 Jul 2012 13:01:15 -0400 Message-ID: To: Stas Malyshev Cc: Rasmus Lerdorf , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=00248c6a66aa5c50d204c4a4e9ee Subject: Re: [PHP-DEV] Iterable Type Hint From: ircmaxell@gmail.com (Anthony Ferrara) --00248c6a66aa5c50d204c4a4e9ee Content-Type: text/plain; charset=ISO-8859-1 Stas, > 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? Well, I'm not so sure that I agree there. If you're passing an incompatible type, it's an application level error, not a runtime level one. And additionally, it enables better defensive programming where code ensures what's passed is what it needs (and the language helps enforce that). Similar to design-by-contract... > 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. I don't think you need boilerplate for every call. Either you create what you're going to pass to said function call, or you type-hint it properly on that method. The onus is on the creator of the variable, not the consumer. Additionally, we could add other is_* functions for these agregate type hints. is_iterable(), etc... > 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. How would downstream affect you? I would understand upstream, but I don't get that point... Could you elaborate further? > > 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. > It's a Recoverable error, so no, it doesn't have no choice but to blow up the whole ap. You can install an error handler and recover from them. The point being that it pushes the call-time checks used by defensive programming into the language instead of as requiring a lot of copy-paste to validate arguments... > Note that no other dynamic language is doing such things. I wonder why. > Well, that's an odd point, because almost all of the other dyanmic typed languages (at least of the popular ones) are object oriented at core. So this sort of type hinting can be done by `assert($obj instanceof Foo)`. With PHP, given the first-class primitives, this is not as straight forward. I'm not saying that we shouldn't take cues from other languages, but to implement or not based on what other languages do is a bit odd, given that PHP is unique in a lot of ways from those other languages... Just my $0.02 at least... Anthony --00248c6a66aa5c50d204c4a4e9ee--