All,
On Wed, Mar 11, 2015 at 11:52 AM, Dan Ackroyd <dan...@basereality.com> wrote:
> Voting no due to:
>
> i) Having conversion rules be difference in userland to internal functions.
>
> You list 'Single Mode' as a benefit of this RFC, but it's only single
> mode if you gloss over this difference. This is a massive cognitive
> load, and will be one of those issues that catches users out again and
> again. Why on earth should a boolean be convertible to int for some
> functions but not others?
>
> What will happen when someone writes code that extends an internal
> class and overrides one of the functions, is that the person who is
> using that extended class will have to alter their code to use the
> extended class in a different way to how they would use the built in
> class directly.
>
> For everyone who didn't pick this up in the RFC, it's hidden in the
> large chunk of text:
> "Unlike user-land scalar type hints, internal functions will accept
> nulls as valid scalars."
>
>
> ii) The subtle BC breaks.
>
> false -> int # No more conversion from bool
> true -> string # No more conversion from bool
>
> btw You appear to have only tested this code against barebones
> frameworks. These are often written far more cleanly than actual
> applications so I don't think the report of 'very limited' BC breaks
> is accurate.
>
>
> iii) Having conversion work, except when they don't. People who want
> weak type hints want weak type hints - they don't want code that
> breaks unexpectedly.
>
> function foo(int $bar){...}
>
> foo(36/$value);
> // works when $value = 1, 2, 3, 4 breaks when $value = 5
>
> This is neither weak nor strict type - this is a horrible hybrid that
> would only catch people out.
>
> But finally, the fact that a significant part of the RFC is talking
> about how the behaviour will need to be cleaned up in a future RFC,
> but at the same time that some of the problems will be left for five
> years show that this isn't a sensible RFC to vote for, even for the
> people who just want weak types
>
> cheers
> Dan
>
In addition, I'm voting no for the following reasons (in addition to Dan's):
1. It downplays the BC breaks. It says:
> Given the change to the acceptable values into a wide range of
internal functions, this RFC is likely to result in a substantial
number of newly introduced E_DEPRECATED warnings in internal function
invocations, although those can be easily suppressed
So BC breaks are fine, as long as they are *easily suppressed*.
This is madness, as they won't be able to be suppressed in 8 (when
they will be turned into hard breaks).
2. It judges the BC breaks based on skeleton applications (Drupal 7's
stock home page, Drupal 7's stock admin interface, Magento's home
page, Wordpress's home page, ZF2's skeleton app, Symfony's ACME app).
It doesn't bring up unit tests (which Symfony was shown to have many
failures). It doesn't show running on non-framework code. It doesn't
show the average Wordpress/Drupal module for example.
3. It contains massive misinformation.
> It is our position that there is no difference at all between
strict and coercive typing in terms of potential future AOT/JIT
development - none at all.
And
> It is the position of several Strict STH proponents that Strict
STH can help static analysis in certain cases. For the same reasons
mentioned above about JIT, we don't believe that is the case -
although it's possible that Strict Typing may be able to help static
analysis in certain edge cases. However, it is our belief that even if
that is true, Static Analyzers need to be designed for Languages,
rather than Languages being designed for Static Analyzers.
Yet the JavaScript community is discovering the exact opposite,
and is looking into a extremely similar dual-mode:
https://developers.google.com/v8/experiments
4. It makes claims against the [dual mode
RFC](https://wiki.php.net/rfc/scalar_type_hints_v5) that apply to this
RFC. For example:
> Too strict may lead to too lax. In the Dual Mode RFC, when in
Strict mode, in many cases, functions would reject values that,
semantically, are acceptable. For example, a “32” (string) value
coming back from an integer column in a database table, would not be
accepted as valid input for a function expecting an integer. Since
semantically the developer is interested in this argument-passing
succeeding, they would have the choice of either removing the integer
STH altogether, or, more likely, explicitly casting the value into an
integer. This would have the opposite of the desired outcome of strict
STHs - as explicit casts ($foo = (int) $foo;) always succeed, and
would happily convert “100 dogs”, “Apples” and even arrays and
booleans into an integer. Further, since already today, internal
functions employ coercion rules that are more restrictive than PHP's
explicit casting, pushing people towards explicit casting will
actually make things worse in case developers opt for explicit casting
as they pass values in an internal function call.
Yet it completely ignores the fact that the identical situation
appears with the coercive mode RFC. The difference is that with
Dual-Mode, it's 100% opt-in, where with coercive you're forced to add
casts.
5. It's full of logical inconsistencies:
For example, given the following code:
function foo(bool $abc) {}
These calls work:
foo(true);
foo(1);
foo("test");
While these fail (note they don't fail on 5.x):
foo(1.0);
foo(array());
foo(null);
Why is `int` accepted for `bool`, but `float` rejected???
And that's not even mentioning that this has been put to vote without
having the final version put up for discussion. There were [12
non-voting related changes in the past 28
hours](https://wiki.php.net/rfc/coercive_sth?do=revisions). Some of
them are likely trivial tweaks, but some like `allow int/string ->
bool conversion` are definitely not trivial. I can't actually pull a
diff of the changes due to errors on wiki.php.net, so I can't tell
exactly what was changed...
I'll open another thread about last-minute changes prior to opening
vote, because that has to stop.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
