Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82109
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <54D6CC39.50708@lerdorf.com>
Date: Sun, 8 Feb 2015 02:51:51 +0000
Cc: =?utf-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <93AAEA55-1C03-46AD-88D0-6A2F5531FCA6@ajf.me>
References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me> <CAB6YZuy-FFERAqcOjtyiizzwUZb6qrnMw8FCf8zur1wsL37Opg@mail.gmail.com> <9E1C2427-0295-4F3E-BD29-04DA84321067@ajf.me> <A3ACFAAF-37CB-47ED-9605-BA7D0609E4DA@ajf.me> <CAB6YZuzW9zwV7F44_8BxcrcteFMW2c3GJq1bkUuZTC9-tcmtNQ@mail.gmail.com> <54D6CC39.50708@lerdorf.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hi Rasmus,

> On 8 Feb 2015, at 02:38, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
>=20
> On 02/07/2015 05:03 PM, Pavel Kou=C5=99il wrote:
>> I'm wishing more and more that the RFC doesn't pass (even though I'd
>> LOVE to have typehints in PHP as a userland developer) and someone
>> else will make a better version of typehints RFC for  PHP 7, because
>> this one feels really like you took an ok-ish RFC (one that would be
>> good for PHP) and slapped a strict typing on it without enough
>> research about strong typing in other languages. And as I said myself
>> multiple times in the past, the declare syntax IS just ugly (and
>> changing how code works by writing one line is an ugly principle as
>> well, IMHO). :(
>=20
> I am not sure I would go that far. Andrea did plenty of research and =
has
> tons of experience in other languages, I just think this approach is
> misguided. I also wonder just how many people of those who voted even
> bothered to download and try the patch. I tried it a while back on =
some
> existing code and it was a nightmare. Does everyone realize that these
> simple things break?
>=20
> tan(1);
> echo strstr("test", "est", 1);

Banning int->float and float->int is both a pain point and sometimes a =
life-saver. It=E2=80=99s annoying that tan(1) doesn=E2=80=99t work. On =
the other hand, you discover if your ints floats would be silently =
truncated (as I did with PictoSwap).

I wouldn=E2=80=99t say that int->string not working is a problem, =
though. Seeing something like strstr(=E2=80=9Ctest=E2=80=9D, =E2=80=9Cest=E2=
=80=9D, 1); is rather confusing. Looking at it, I=E2=80=99d think the =
third parameter is some sort of number for you to want to pass an =
integer to it. If I want a string, I=E2=80=99ll use one.

> Having absolutely no coercion for int to float and 0/1 to false/true,
> especially for internal functions, is just too pedantic to me. I also
> find this a bit hypocritical:
>=20
> declare(strict_types=3Dtrue);
>=20
> outputs:
>=20
> Fatal error: strict_types declaration must have 0 or 1 as its value
>=20
> That is obviously nit-picking, but if we are going to get this =
pedantic=E2=80=A6

Yes, that is a cruel irony that I did notice when I changed it. I =
sacrificed strictness/=E2=80=9Ccorrectness=E2=80=9D there for brevity. =
The reason you can=E2=80=99t use a boolean is that I think it=E2=80=99s =
better if only two forms are allowed (=3D0 and =3D1) - less forms to =
remember, less ambiguity.

> And, you also have to realize that it isn't actually per file. For
> example, this:
>=20
> <?php
> function myErrorHandler($errno, $errstr, $errfile, $errline) {
>  if ($errno=3D=3D=3DE_RECOVERABLE_ERROR) {
>    echo "\ncatchable fatal error\n";
>    return true;
>  }
>  return false;
> }
> set_error_handler('myErrorHandler');
>=20
> echo tan(1);
> declare(strict_types=3D1);
> echo tan(1);
> declare(strict_types=3D0);
> echo tan(1);
>=20
> This will output:
>=20
> 1.5574077246549
> catchable fatal error
> 1.5574077246549
>=20
> The RFC refers to it as a per-file directive, which just means it
> doesn't apply to files you include after setting it. It doesn't mean
> that the entire file is affected. You can flip in and out of strict =
mode
> at will. Which isn't necessarily a bad thing, but it can certainly get
> confusing.

Yes, the RFC is somewhat inaccurate in that respect. It is per-file in =
one sense (like encoding, but unlike ticks, it has no effect on the =
including or included files). However, it technically affects the =
remainder of the file, not the whole file.

> For example. Since everyone has already voted, you can all tell me =
what
> this does, right?
>=20
> 1)
> <?php
> function do_something() {
>  declare(strict_types=3D1);
> }
> echo tan(1);
> do_something();
> echo tan(1);

I don=E2=80=99t understand why it=E2=80=99s even allowed for the =
declare() statement to be used like that (why is a compile-time option =
allowed to be within a function? That=E2=80=99s a recipe for disaster), =
but that would make the first tan(1); error and halt program execution.

> How about this:
>=20
> 2)
> <?php
> echo tan(1);
> do_something();
> echo tan(1);
> function do_something() {
>  declare(strict_types=3D1);
> }

First two calls succeed. Again, declare()=E2=80=99s behaviour is =
weird=E2=80=A6 makes me wonder who thought it was a good idea to allow =
this.

> or this?
>=20
> 3)
> <?php
> function do_something() {
>  declare(strict_types=3D1);
> }
> echo tan(1);
> echo tan(1);

That would make the first tan(1); error and halt program execution.

> Answers:
>=20
> 1) fatal error on the first tan(1)
> 2) no errors
> 3) same as 1)

Hooray, I guessed right.

> Basically declare() does not respect function scope, but it doesn't =
let
> you know that. There is a reason we haven't used declare() for =
anything
> real.

I wonder if we should just remove this ability of declare(); or at least =
produce some sort of warning (E_DEPRECATED? E_WARNING? E_STRICT?). =
It=E2=80=99s highly misleading and I don=E2=80=99t really understand why =
it=E2=80=99s allowed.

Then again, that would cause problems for ticks, possibly?
--
Andrea Faulds
http://ajf.me/