On Sun, Jan 19, 2014 at 1:16 AM, Sherif Ramadan <[email protected]> wrote:
> 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.
I'm a little stunned by this response. By no means is this RFC fluff,
and simply because you do not personally see a use case does not mean
that they do not exist.
Currently I am working on a HTTP Message PSR, where we would like an
array of instances of the HeaderValueInterface to be sent through to a
method. Currently we have to type-hint against "array" and hope the
user knows what they are supposed to send through with documentation.
Interfaces are meant to be a contractual obligation, not guesswork.
That might seem like an edge case, but this happens all the time.
PyroCMS wants an array of Widgets, or ModuleDetails, or anything.
Boilerplate code for these occasions is always required and its a pain
in the ass having to write it every time.
To me it is confusing that there is a separation in the "usefulness"
between type hinting a single item, or type hinting an array of items.
For the same reason I want to be certain that an argument is a Foo, I
want to know if I am being given multiple Foo's.
"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."
It's wonderful that PHP allows arrays to be so vague. It's truely
useful sometimes. Sometimes its not and I want to know exactly what is
in there, as is the right of the implementor of a function or method.
When I want to know that everything is a Foo it would be great to
ensure that.
Again I say I am confused how this is a marginal requirement, this is
incredibly standard stuff.
"Ultimately the user just gets confused and doesn't tend to find these
limiting syntax sugars all that useful in practice."
Who is the user? The user implementing the type hint? If they want it,
they will use it. If they dont want it, they wont use it.
Somebody calling said function or method is going to get an error if
they dont pass in the correct data, just like any other type hint. So
again, there is not a lot of room for confusion there.
"It doesn't actually make the code any easier to read and doesn't make
it any easier to debug"
I strongly disagree with this statement.
Currently if a function is expecting Foo's you need to either read a
DocBlock, external documentation or read the code. Seeing Foo[] let's
you know that you need an array of Foo's, right there in the
declaration. That is what I consider to be readable, but I understand
you might say the square brackets could cause confusion to the user.
I know you can't google search for "[]", but the docs would be right
there on the "type-hinting documentation" so that solves that nicely.
"Code that uses the new syntax tends to get trapped into too many edge cases"
Not sure what you mean here. If I want a bag of spanners I know that
I'm getting a bag of spanners. That does not trap me, it is a safety
catch, to make sure when I put my hand in the bag it is always going
to be a spanner, and I don't accidentally pull out a bear.
I think mostly I would just like you to quantify some of your
statements, as you seem to be saying:
1. It is only useful to people called Jeremy on a Tuesday afternoon
2. It is single-handedly responsible for the death of Steve Jobs.
3. Explosions
I think its a nice logical improvement which syntactically offers a
replacement for looney boilerplate code, exactly like Variadics which
a LOT of people are excited about.