Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84551
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.160.180 cause and error)
MIME-Version: 1.0
In-Reply-To: <ff8e8d5564b00b7baead3d9dd46282c8@mail.gmail.com>
References: <ff8e8d5564b00b7baead3d9dd46282c8@mail.gmail.com>
Date: Wed, 11 Mar 2015 15:52:55 +0000
Message-ID: <CA+kxMuTg6kpX4oTVfJQbBRQB5RyuJbH5qLJOrrj098sDRW4Geg@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
From: danack@basereality.com (Dan Ackroyd)

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

.

On 11 March 2015 at 15:10, Zeev Suraski <zeev@zend.com> wrote:
> The vote on the Coercive Scalar Type Hints is now open for voting.
>
>
>
> The latest version of the RFC includes changes discussed on internals@ last
> week:
>
> 1.  Accept string->bool and int->bool conversions (false->bool is not
> supported)
>
> 2.  Accept leading/trailing spaces in string->number conversions.
>
>
>
> wiki.php.net/rfc/coercive_sth
>
> wiki.php.net/rfc/coercive_sth#vote
>
>
>
> Thanks!
>
>
>
> Zeev