Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84561
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.212.178 as permitted sender)
References: <ff8e8d5564b00b7baead3d9dd46282c8@mail.gmail.com>
	<CA+kxMuTg6kpX4oTVfJQbBRQB5RyuJbH5qLJOrrj098sDRW4Geg@mail.gmail.com> <CAAyV7nE=tCNeUdROf=++xRGKHYWXXsFW26z9JPzgZCmP=FAxUQ@mail.gmail.com>
In-Reply-To: <CAAyV7nE=tCNeUdROf=++xRGKHYWXXsFW26z9JPzgZCmP=FAxUQ@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQKPOnWVaAuYgcCmzEA2Wd2iOMMQuAFOokdaAR+jD5Kbhk8XIA==
Date: Wed, 11 Mar 2015 19:15:45 +0200
Message-ID: <413f4e69e0d87eddc1b71e834e866426@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
From: zeev@zend.com (Zeev Suraski)

> 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).

If you copied the whole paragraph (one more sentence) instead of it out of
context it would be clear that we're not at all downplaying anything.  We'r=
e
portraying it exactly for what it is, for better or worse.
The fact users would have years to adjust is radically different from if we
broke compatibility overnight, and that's exactly what this paragraph
conveys.

> 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.

I don't consider Drupal/Magento or WordPress framework code.  It's real
world apps, very very similar to other custom-coded real world apps.

> 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 a=
t
> all.

It's our position, the position of people very well versed in this area tha=
t
have written a JIT compiler that runs blazingly fast with no type hints at
all.  It's fine that you have a different opinion.  One of us is wrong.

>     Yet the JavaScript community is discovering the exact opposite, and i=
s
> looking into a extremely similar dual-mode:
> https://developers.google.com/v8/experiments

This is hardly the exact opposite.  It means something we agreed on from th=
e
get go - if you *change* your code so that the compiler can gain more
insight on what the types are during compile-time (e.g. an explicit cast, o=
r
if we add typed variable declarations) - then sure,  there'll be AOT/JIT
gains - but they're absolutely not coming from the difference in type hints=
.
I still contend that with coercive type hints we can perform the exact same
static analysis, with just differently phrased output such as  "it may need
to be converted" rather than "will be rejected".   Identical type inference
rules.  Identical everything, just slightly modified text.

> 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 Stric=
t
> mode, in many cases, functions would reject values that, semantically, ar=
e
> acceptable. For example, a =E2=80=9C32=E2=80=9D (string) value coming bac=
k 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 outcom=
e
> of strict STHs - as explicit casts ($foo =3D (int) $foo;) always succeed,
> and
> would happily convert =E2=80=9C100 dogs=E2=80=9D, =E2=80=9CApples=E2=80=
=9D 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.

That's one difference, but the real difference is that the rules are
radically - and the coercive ones are what you'd almost always want to use
in real life, while strict almost never is - which means a lot more explici=
t
casts.  The most popular conversion in PHP - string -> number - just works.
With strict mode, it simply doesn't.   Personally, I think that the 'it
won't break until you actually flip it on' stance is weak.  When people do
flip it on (and they'd certainly be encouraged to do so by many people, e.g=
.
your blog post from a few weeks ago) - they're going to see massive breakag=
e
which will in turn require massive explicit casting - resulting in much
worse code than in the coercive type hints case.

> 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???

Because int is commonly used in boolean context, which cannot be said about
float (if you discount the PHP test suite, that is).  This patch tries to
provide real-world value and support real-world use cases - and blocks ones
which are more than likely to be mistakes.  The rules are designed to work
in the vast majority of cases and support all the sensible conversions.  Yo=
u
can always use explicit casting or otherwise refactor your code if you do
bump into some edge case - but fact is, you'd bump into a lot less problems
than if you flip on strict.

> 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 relate=
d
> changes in the past 28
> hours](https://wiki.php.net/rfc/coercive_sth?do=3Drevisions). Some of the=
m
> 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...

In terms of behavior that's the only thing that changed, and those were
discussed publicly over a week ago.  Guys, this isn't House Of Cards.  Let'=
s
stay focused on substance.

Zeev