Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83592
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nFR4os6Go7j-S_TT9Gt-Y38ZMJpN6PXs9Li6C1H3+ee=w@mail.gmail.com>
References: <CACouGvnY3rDDcpfZAv7pkv0ZgLTwUA_4g6m3_R3yDRScncbFrA@mail.gmail.com>
	<CAAyV7nFR4os6Go7j-S_TT9Gt-Y38ZMJpN6PXs9Li6C1H3+ee=w@mail.gmail.com>
Date: Mon, 23 Feb 2015 11:21:50 -0600
Message-ID: <CACouGvndU2U9AoV+=gH0rRLCX=i-gPSNXA+YjhrCq73=1cpaqA@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] User perspective on STH
From: matthew@zend.com ("Matthew Weier O'Phinney")

On Mon, Feb 23, 2015 at 10:21 AM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
<snip>

> And what about other languages that have exactly this behavior? Such
> as Go/Hack/Haskell/etc. Do you see casts everywhere? No. You see them
> where it needs to be explicit. Otherwise, people just write using the
> correct types.
>
> And it also hand-waves over the fact that the same problem exists with
> coercive types. You're going to get the error anyway if you try to
> pass "apple" to an int parameter. So if someone was going to cast with
> strict, they will cast with coercive.

True. But you're also hand-waving over a point I brought up: many,
many input sources for PHP return strings: HTTP calls, database calls,
etc. With coercive mode, I can pass these values on to other function
calls without a problem; with strict mode, I cannot; I MUST cast
first.

<snip>

>> If I don't enable strict mode on my code, and somebody else turns on strict when
>> calling my code, there's the possibility of new errors if I do not perform
>> validation or casting on such values. This means that the de facto standard will
>> likely be to code to strict (I can already envision the flood of PRs against OSS
>> projects for these issues).
>
> Incorrect. The only person that can turn on strict mode is you, the
> author. Now someone can install your library, and edit it to turn on
> strict mode (add the declares at the top of the file). But that's very
> different from what strict proposes.

Okay, I'm confused then.

Let's consider this scenario:

I have a library. It does _not_ declare strict. It _does_ make calls
to either a web service or a database. Let's get even more specific:
the code does _not_ define any _scalar_ type hints, but accepts a
callable.

    function execute(callable $callback)
    {
        // fetch some data from a web service or database,
        // gather item1 and item 2 from it,
        // and pass the data on to the callback, which was passed to us.
        // Assume that we know that item1 is an int-like value, and
item2 is a string-like value.
        $callback($item1, $item2);
    }

You, as a consumer, declare your script in strict mode, and make a
call to my own code.

    declare(strict_types=1);
    // somehow import the above function

    $callback = function (int $item1, string $item2) {
        // do something with the items...
    };
    execute($callback);

How does that operate?

https://wiki.php.net/rfc/scalar_type_hints_v5 indicates that the
caller determines strict mode, but I'm unclear what the scope of that
is: does it bubble down the entire stack? or does strict only apply to
the specific calls made (i.e., before it reaches the function/method
declared in the other file)? What happens when $callback is executed,
and $item1 is '10'? Is it interpreted strictly, or weakly? Where is
the boundary for where strict happens, exactly?

If strict only applies to the execute() invocation, and doesn't apply
to $callback or the calls made to the web service or database, then I
can retract my statements; however, if the strict applies all the way
down the stack from the caller, I can see definite issues. That's what
I'm worried about.

<snip>

> However, with 2/3 of the options presented in the coercive RFC, you'll
> have an INI setting that changes the behavior of your code for you
> (the other 1/3 is potentially a significant BC break). How is that
> better than a per-file switch? Something you as a library developer
> have no control over...

Personally, I'd prefer no INI switch, but I also recognize the BC
problems with that RFC. I want to note now, I'm not saying I support
either RFC specifically; my concern is with the dual-mode aspect of
the STH v0.5 (and predecessors).

<snip>

>> This is what I want from STH, no more no less: sane casting rules, and the
>> ability to code to scalar types safely. While I can see some of the benefits of
>> strict mode, I'm concerned about the schism it may create in the PHP library
>> ecosystem, and that many of the benefits of the coercive portion of that RFC
>> will be lost when working with data from unknown data sources.
>
> Considering the strict mode is file-local, it's not all or nothing.
> It's up to the author writing code to determine how to handle the
> calls (s)he will make.

And, as noted, that's the part I need clarification on: is it really
local only to calls made directly in that file, or does strict follow
all the way down the chain?

Finally, there's the other aspect of type casting coercion from the
competing RFC, https://wiki.php.net/rfc/coercive_sth. The tables in
there make a lot of sense to me, as do the eventual ramifications on
language consistency. If dual-mode is really restricted only to the
direct calls made in the given file, and does not travel all the way
down the callstack, the ideal STH proposal, to me, would be combining
the aspects of the second proposal with regards to type coercion with
the dual-mode.

-- 
Matthew Weier O'Phinney
Principal Engineer
Project Lead, Zend Framework and Apigility
matthew@zend.com
http://framework.zend.com
http://apigility.org
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc