Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71266 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96534 invoked from network); 19 Jan 2014 06:16:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Jan 2014 06:16:46 -0000 Authentication-Results: pb1.pair.com header.from=theanomaly.is@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=theanomaly.is@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.52 as permitted sender) X-PHP-List-Original-Sender: theanomaly.is@gmail.com X-Host-Fingerprint: 74.125.82.52 mail-wg0-f52.google.com Received: from [74.125.82.52] ([74.125.82.52:47628] helo=mail-wg0-f52.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AB/E5-61840-DCD6BD25 for ; Sun, 19 Jan 2014 01:16:46 -0500 Received: by mail-wg0-f52.google.com with SMTP id b13so5793022wgh.31 for ; Sat, 18 Jan 2014 22:16:42 -0800 (PST) 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=uSXOvK/2hXt/Hlv4JXqqm/SsNJtrhGQnn+yP4wdVxDg=; b=iDj8skJwrRe6pQFqgdNz7ndXY189FqLQNORqdSSjGI5RZoVmPEl/QEug4uGXfeaiT7 zA63hVuv2zdKIJW5CHdWudEsCMdWTVNlKbWpYiwRWxK6uf32v6EMkMXo6J+Exzztwc3F C558Ml1jTcTVmFgEJRBT7HSGteWuuRVe6TaXSb2wPpOIni9vEzEQJEKU5MCuchWShBVM Eo3GuNmcoC2nXRQ6lec80RTNfZ/4I4o2jxLAbgGghgqdaoeFFau8hrv/PKNFs+5NcanU 59mezaZFRq6VUCi8TleqyB44ZML+OkVRlx+fdUDX+TG613G/Q/xDOTRV0E4kh0u3HchX O9BA== MIME-Version: 1.0 X-Received: by 10.194.161.136 with SMTP id xs8mr37967wjb.56.1390112202799; Sat, 18 Jan 2014 22:16:42 -0800 (PST) Received: by 10.227.32.135 with HTTP; Sat, 18 Jan 2014 22:16:42 -0800 (PST) In-Reply-To: References: <001301cf1227$6d082ab0$47188010$@tutteli.ch> <002d01cf1234$01e6dc60$05b49520$@tutteli.ch> <004c01cf123d$35730870$a0591950$@tutteli.ch> <52D71748.1090402@googlemail.com> <52D71FAE.8030002@ajf.me> <005001cf124f$3a40df00$aec29d00$@tutteli.ch> <20140116110127.202079vzjsj76n7b@webmail.tutteli.ch> <0B.B1.24763.139B7D25@pb1.pair.com> <002001cf12da$2bfbda90$83f38fb0$@tutteli.ch> Date: Sun, 19 Jan 2014 01:16:42 -0500 Message-ID: To: Chris Wright Cc: Mark Tomlin , PHP Internals Content-Type: multipart/alternative; boundary=089e013cc30a0bc02a04f04cb866 Subject: Re: [PHP-DEV] Introducing "Array Of" RFC From: theanomaly.is@gmail.com (Sherif Ramadan) --089e013cc30a0bc02a04f04cb866 Content-Type: text/plain; charset=ISO-8859-1 This RFC seems to purport in the way of improvement. I feel it's more of a variation than an improvement on the status quo. We've had a number of these RFCs over the years. I'd be much more interested to see RFCs that introduce an actual lacking feature into the language like the exponent operator RFC rather than all of these OOP syntax sugar RFCs that are cropping up by the minute. I'm not trying to bash anyone's efforts, but I really feel that these kinds of RFCs are mostly fluff that we could easily do without. To focus specifically on this RFC I find its use cases to be extremely limiting and mildly beneficial. PHP arrays are very generalized so that a developer could easily have an array of integers, floats, strings, and any other primitive in the same storage unit. To limit the type hinting just to user-defined objects and then limit it even further to a single dimension means chopping the number of use cases down to an 8th then chopping that number down by another fraction. The result is such a narrow use case that it becomes almost useless in practice. The idea of better type hinting in PHP is not inherently a bad one. It's just that many of the proposed implementations seem to veer off into fragile use cases that really shouldn't require a language change. What's worse is that the next RFC to come after it usually makes it worse as it tries to pull the language into an equally different set of fragile use cases. Ultimately the user just gets confused and doesn't tend to find these limiting syntax sugars all that useful in practice. Even though they appear interesting in theory, they're not really so great that we couldn't do with a pure PHP implementation that doesn't require a language change. Having looked over the RFC and the actual patch I find that refactoring code which relies on the function or method itself to handle type checks (in situations where it will cause an actual broken design by contract effect), makes the patch a worser scenario for both the developer and the language. It doesn't actually make the code any easier to read and doesn't make it any easier to debug. Code that already relies on PHP implemented type checks is better off not using the new syntax. Code that uses the new syntax tends to get trapped into too many edge cases. So I really can't see the upside here. --089e013cc30a0bc02a04f04cb866--