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 [email protected] 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.


Thread (73 messages)

« previous php.internals (#71266) next »