Re: Introducing "Array Of" RFC

From: Date: Sun, 19 Jan 2014 06:16:42 +0000
Subject: Re: Introducing "Array Of" RFC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19  Groups: php.internals 
Request: Send a blank email to internals+get-71266@lists.php.net to get a copy of this message
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.

« previous php.internals (#71266) next »