Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85033
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.46 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <op.xvk9kzcdc9evq2@nikita-pc>
References: <CABBJUpfiy1BpdyZ5MJmQb3vQz9U8TkSECHCRctupV+BUG1H=fw@mail.gmail.com>
 <CAEZPtU7qa9N+4HYdtjseN4K83e0Oy8rZDi8FbXfJ9Zp0ks6rRg@mail.gmail.com>
 <CABBJUpe_fUiwuJw5Q-u+ntVOyVU-xN+C2EFL79TmJJu7Gmh38w@mail.gmail.com>
 <alpine.DEB.2.11.1503161113020.4205@whisky.home.derickrethans.nl>
 <CAGa2bXZm_ph9=TV_7oLB7NWSkX1iCpXqBiYVROQiKCFujrHJCQ@mail.gmail.com> <op.xvk9kzcdc9evq2@nikita-pc>
Date: Mon, 16 Mar 2015 20:50:16 +0900
Message-ID: <CAGa2bXa6azNxq_1=61xcE3ZEuBne32LpUycaddPbLckhR9CDwg@mail.gmail.com>
To: Nikita Nefedov <inefedor@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013c5ca8825cb505116676f4
Subject: Re: [PHP-DEV] About declare(strict_types = 1)
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e013c5ca8825cb505116676f4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 16, 2015 at 8:44 PM, Nikita Nefedov <inefedor@gmail.com> wrote:

> On Mon, 16 Mar 2015 14:33:00 +0300, Yasuo Ohgaki <yohgaki@ohgaki.net>
> wrote:
>
>  Hi Derick,
>>
>> On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans <derick@php.net> wrote:
>>
>>  To be frank, I don't think "I don't like this" is a terribly good reaso=
n
>>> to vote against (or for something). What is important is how many peopl=
e
>>> would actually benefit from a feature, without it causing issues for
>>> others. I am certainly no fan of the "declare" *syntax*, but I do know,
>>> from talking at conferences that many many developers would like to see
>>> scalar type hints in some way =E2=80=94 both weak (mode 1 of the STHv5 =
RFC), and
>>> strict (mode 2). It even caters for people that don't want to use them
>>> at all, as they can simply not use them. I also know, that without a
>>> dual mode, it seems very unlikely for scalar type hints to make it
>>> into PHP 7, and I don't think that is what users want. As this is our
>>> *best* bet, I can only vote "yes".
>>>
>>
>>
>> Are you sure on your bet?
>>
>> lib.php:
>> <?php
>>         declare(strict_types =3D 1);
>>         function foo(int $a) {
>>         // no function call here
>>         }
>> ?>
>> The declare here does just nothing.
>>
>> a.php:
>> <?php
>>         require "lib.php";
>>         foo("123"); // will work
>> ?>
>>
>> b.php:
>> <?php
>>         declare(strict_types =3D 1);
>>         require "lib.php";
>>         foo("123"); // will give an error
>> ?>
>>
>> This behavior is unacceptable.
>> Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
>> work as it should. Otherwise, all kinds of unexpected for lib.php and it=
's
>> users may happen.
>>
>
> When called from a.php, foo() will get and int(123), this is exactly what
> is expected. Author of a.php acknowledges that all arguments in fcalls fr=
om
> this file will be converted to appropriate types, this is basically how a=
ll
> our internal functions work currently and it's perfectly acceptable. But =
if
> you don't want this kind of type juggling then you opt-in strict types.
> This is basically as easy as it gets, I don't see any way to make it
> simpler. There's nothing to evolve in this RFC, it covers pretty much
> everything and the idea of allowing for caller to make a decision is, in =
my
> opinion, a great win in this situation.


I already showed real world example how this could be fail.

If we need this kind of behavior. I would suggest to have type affinity
like SQLite for
$_GET/$_POST/$_COOKIE.

https://www.sqlite.org/datatype3.html

This would work better to work with strict types.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e013c5ca8825cb505116676f4--