Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83593
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 209.85.212.180 cause and error)
MIME-Version: 1.0
In-Reply-To: <CACouGvndU2U9AoV+=gH0rRLCX=i-gPSNXA+YjhrCq73=1cpaqA@mail.gmail.com>
References: <CACouGvnY3rDDcpfZAv7pkv0ZgLTwUA_4g6m3_R3yDRScncbFrA@mail.gmail.com>
	<CAAyV7nFR4os6Go7j-S_TT9Gt-Y38ZMJpN6PXs9Li6C1H3+ee=w@mail.gmail.com>
	<CACouGvndU2U9AoV+=gH0rRLCX=i-gPSNXA+YjhrCq73=1cpaqA@mail.gmail.com>
Date: Mon, 23 Feb 2015 18:26:01 +0100
Message-ID: <CAEPJdu=OjtjMeysCCbuHgwz57PeOo-FZfEig09EtspT-O8RCFw@mail.gmail.com>
To: "Matthew Weier O'Phinney" <matthew@zend.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c389103489c7050fc4b25a
Subject: Re: [PHP-DEV] User perspective on STH
From: kontakt@beberlei.de (Benjamin Eberlei)

--001a11c389103489c7050fc4b25a
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 23, 2015 at 6:21 PM, Matthew Weier O'Phinney <matthew@zend.com>
wrote:

> 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?
>

This may give an error, but this is totaally the fault of the
strict_types=1 user.
Why does he define a typehint for a closure that is passed to non
typehinted code?
Its a bug he has introduced himself.

This is the only example you can construct to support your view, but its
conceptually flawed.
A bug on the side of the strict developer.


>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11c389103489c7050fc4b25a--