Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98471
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D231949A-8A25-4BFF-A50B-553A70BE6B1E@gmail.com>
References: <CAPhkiZzs=kLF-JKBjX4bVgADz+nonERWuZYiYo8cXA=GrXKU=g@mail.gmail.com>
 <f60b8e05-c5d8-0437-37b5-a4b23911fdbb@fleshgrinder.com> <fb25f8bc-2b7c-a27d-6861-039b67c19971@gmail.com>
 <CAPhkiZzus6-LW8g-fxeBYymEq2FGLOfMS2DKZ16KPOXfaxr+AQ@mail.gmail.com>
 <24efb0e7-b0e3-68ed-5f42-2d5481f8f291@gmail.com> <CAPhkiZwr0Xff-+NR1OE7cnVD7AoHKRBR43h0S76TfWdrjK6kaA@mail.gmail.com>
 <44add374-6c4b-399a-c542-8d7f100dfaa3@fleshgrinder.com> <CAPhkiZyFOxDgubcdpxwSXVRVjim-2ALzN9gYs7D6gvf6UXqeAw@mail.gmail.com>
 <cb81577f-5f0f-b10c-902c-2f17e7fc145b@fleshgrinder.com> <CAPhkiZz6dm4ySNJTD_j21DKcGGGDPZnAUFUp_wOt9XBQfFFgzA@mail.gmail.com>
 <D231949A-8A25-4BFF-A50B-553A70BE6B1E@gmail.com>
Date: Fri, 10 Mar 2017 17:11:39 +0200
Message-ID: <CAPhkiZyi79b5b2psvvCdKnOJN8j4gQpeFs=JwOjHewEGqv3dyw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [Discussion] is_string(), string type and objects
 implementing __toString()
From: narf@devilix.net (Andrey Andreev)

On Fri, Mar 10, 2017 at 4:20 PM, Rowan Collins <rowan.collins@gmail.com> wr=
ote:
> On 10 March 2017 10:57:42 GMT+00:00, Andrey Andreev <narf@devilix.net> wr=
ote:
>>I'm not really interested in making "strict mode" less strict - it's
>>already opt-in and non-enforceable.
>>I want ways to write stonger-type code in "non-strict mode", because
>>the fact that "strict mode" is non-enforceable means I can never rely
>>on it.
>
> This is a common misconception - you can absolutely rely on strict mode e=
nforcing your contract.
>
> Basically all that happens in non-strict mode is that if the caller write=
s:
>
> foo($value);
>
> The compiler automatically changes that to:
>
> foo((string)$value);
>
> (That's not literally how it's implemented, but it's the effect you get.)
>

If I want to enforce strict_types=3D1 operation on the caller - I can't,
it can always be overriden, and thus I can never rely on it.
The fact that strict_types=3D0 will do casting for me has no relation to th=
is.

If there's any misconception here, it is that both modes are equal -
if they were, we wouldn't have 2 of them.

> As the receiver of that parameter, you can't tell, and don't care, if it =
was the human writing the code who added the cast, or the compiler adding i=
t for them.
>

You don't, but I do care at times.
I want to know that the *caller* gave me what I want, and that the
compiler didn't modify it before I received it.

Why I may care about that is a different question, and nototiously
hard to explain to people who don't, as all you'd always say something
like "you asked for an integer and got an integer" ...
Let's say I asked for one of 3 class constants, that happen to hold
integer values, and you gave me a string that just happens to be
castable to one of those values - you obviously aren't using my API
correctly, but I have no way of telling you this because the compiled
hid it from both of us.

These cases may be rare and very specific, but they do exist and are
valid. Yet for some reason, very few people around here want to admit
that - all in the name of keeping PHP a weakly-typed language all the
way. As if adding one feature would all of a sudden change your
ability to write the same code you always did.

Sorry about the rant, you can probably tell this irritates me a lot
and I can't help it. I'll shut up now, just don't go on a mission to
convince me otherwise - won't ever work.

> You can't detect someone blindly writing "(string)" everywhere any more t=
han you can detect whether they are running in strict mode. Nor can you kno=
w if they took it straight from unfiltered user input, or copy-pasted a lit=
eral string to 10 different files, or a hundred other things you'd really l=
ike them not to do. All you know is, you asked for a string, and you got on=
e.
>

... exactly - uncertainty all over the place. :)

Cheers,
Andrey.