Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123720
Precedence: bulk
MIME-Version: 1.0
References: <CAPzBOBMidokE3xw251f+_qbCPAyQQRcN1WnyVF0xfuzaPBU3JA@mail.gmail.com>
 <9d28c9tOCChpWUcP1SFiFwtf2-w2XAtDzHsmM73myA7zfBsn7TxxEqs-VCnxRAgZjsk2TxS55owmM8wSLgBQL8LgeQLntUQ9toeLMkjTVx4=@gpb.moe>
 <673a1803-83c4-44b4-bd73-4ba61e83412e@app.fastmail.com> <350c1531-9bcf-4e7c-824b-8d9904b9e48e@rwec.co.uk>
In-Reply-To: <350c1531-9bcf-4e7c-824b-8d9904b9e48e@rwec.co.uk>
Date: Fri, 21 Jun 2024 10:12:34 +0100
Message-ID: <CAKxcST_zA=F_tLV+FOM08is5KHcw58EpfvvZGNfw7VPOAYsLnQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000afc31d061b62d591"
From: dragoonis@gmail.com (Paul Dragoonis)

--000000000000afc31d061b62d591
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 20, 2024 at 11:54=E2=80=AFPM Rowan Tommins [IMSoP] <imsop.php@r=
wec.co.uk>
wrote:

> On 19/06/2024 16:34, Larry Garfield wrote:
>
> Also, as someone who does put every file into strict mode as a matter of
>  course, and appreciates the many languages that do not even have a
> concept of non-strict mode (like Go or Rust), I really don't appreciate
> the backhanded comments in this thread about people who, you know, care
> about type safety.  (Something that weak mode, when it was introduced in
>  PHP 7, only marginally provided if at all.)  Strict mode prevents bugs,
>  full stop, and we should not fault anyone for applying that bug-stopper
>  tool liberally.
>
>
>
Hey Rowan,

What Gina, Larry and Sebastian said.

My $0.02 is

1. typing "declare(strict_types=3D1);" is already cumbersome enough, we don=
't
need to be adding more words and complexity to it

2. adding the word "coerce" or "coercion" to a thing is really not good
from a DX (developer experience) perspective. It will not add clarity it
will add *confusion*... "What is this coersion thing I've never heard of"

3. remember who the target audience is.. Rust and Golang are not
beginner-friendly or entry-level languages, so the fact you're even using
Rust means you know what you're doing and likely know what coersion is

3.1 PHP's strength is that it's beginner friendly and by that I mean just
remember a significant portion of our userbase are Wordpress developers
(and Drupal / Magento alike) .. and many WP devs won't have even heard of
Dependency Injection before nevermind the complexities of type coersion, so
we need to keep things *simple as possible* at all times

4. I think the solution you're looking here for is better *education* to
the end-users, on what the implications of X or Y are .. rather than
changing the language itself .. so the merits of your proposal are good, in
that it helps the end-user understand the system better .. it's just the
solution you're proposing here just isn't it (so far).



Used correctly, it absolutely does. Used incorrectly, it can actually end
> up *hiding* errors.
>
> I've seen lots of cases where code like this:
>
> some_function_expecting_int($_GET['foo']);
>
> Gets changed to this:
>
> declare(strict_types=3D1);
> some_function_expecting_int( (int)$_GET['foo'] );
>
> Even in PHP 7.0, the first version is actually *stricter* than the second=
,
> because explicit casts never fail, but parameter coercion (mode 0) always
> failed for strings like "hello"; as of 8.0, it also fails for strings lik=
e
> "123foo" and "".
>
> And this is exactly the kind of code that coercive type hints were
> intended for - HTTP is a text-based protocol, so most PHP applications ar=
e
> dealing with string input and output *all the time*.
>
> One of the things the language badly needs, and I have been trying to com=
e
> up with a proposal for, is strict type casts, so that this code can
> actually be written safely but still concisely.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
>

--000000000000afc31d061b62d591
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 20, 2024 at 11:54=E2=80=
=AFPM Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">ims=
op.php@rwec.co.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><u></u>

 =20
   =20
 =20
  <div>
    <div>On 19/06/2024 16:34, Larry Garfield
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>Also, as someone who does put every file into strict mode as a m=
atter of
 course, and appreciates the many languages that do not even have a=20
concept of non-strict mode (like Go or Rust), I really don&#39;t appreciate=
=20
the backhanded comments in this thread about people who, you know, care=20
about type safety.  (Something that weak mode, when it was introduced in
 PHP 7, only marginally provided if at all.)  Strict mode prevents bugs,
 full stop, and we should not fault anyone for applying that bug-stopper
 tool liberally.</pre>
    </blockquote>
    <p><br></p></div></blockquote><div><br></div><div>Hey Rowan,</div><div>=
<br></div><div>What Gina, Larry and Sebastian said.</div><div><br></div><di=
v>My $0.02 is</div><div><br></div><div>1. typing=C2=A0&quot;declare(strict_=
types=3D1);&quot; is already cumbersome enough, we don&#39;t need to be add=
ing more words and complexity to it<br><br></div><div>2. adding the word &q=
uot;coerce&quot; or &quot;coercion&quot; to a thing is really not good from=
 a DX (developer experience) perspective. It will not add clarity it will a=
dd *confusion*... &quot;What is this coersion thing I&#39;ve never heard of=
&quot;</div><div><br></div><div>3. remember who the target audience is.. Ru=
st and Golang are not beginner-friendly or entry-level languages, so the fa=
ct you&#39;re even using Rust means you know what you&#39;re doing and like=
ly know what coersion=C2=A0is</div><div><br></div><div>3.1 PHP&#39;s streng=
th is that it&#39;s beginner friendly and by that I mean just remember a si=
gnificant portion of our userbase=C2=A0are Wordpress developers (and Drupal=
 / Magento alike) .. and many WP devs won&#39;t have even heard of Dependen=
cy Injection before nevermind the complexities of type coersion, so we need=
 to keep things *simple as possible* at all times</div><div><br></div><div>=
4. I think the solution you&#39;re looking here for is better *education* t=
o the end-users, on what the implications of X or Y are .. rather than chan=
ging the language itself .. so the merits of your proposal are good, in tha=
t it helps the end-user understand the system better .. it&#39;s just the s=
olution you&#39;re proposing here just isn&#39;t it (so far).</div><div><br=
></div><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div><p>
    </p>
    <p>Used correctly, it absolutely does. Used incorrectly, it can
      actually end up *hiding* errors.</p>
    <p>I&#39;ve seen lots of cases where code like this:</p>
    <p>some_function_expecting_int($_GET[&#39;foo&#39;]);</p>
    <p>Gets changed to this:</p>
    <p>declare(strict_types=3D1);<br>
      some_function_expecting_int( (int)$_GET[&#39;foo&#39;] );</p>
    <p>Even in PHP 7.0, the first version is actually *stricter* than
      the second, because explicit casts never fail, but parameter
      coercion (mode 0) always failed for strings like &quot;hello&quot;; a=
s of
      8.0, it also fails for strings like &quot;123foo&quot; and &quot;&quo=
t;.<br>
    </p>
    <p>And this is exactly the kind of code that coercive type hints
      were intended for - HTTP is a text-based protocol, so most PHP
      applications are dealing with string input and output *all the
      time*.<br>
    </p>
    <p>One of the things the language badly needs, and I have been
      trying to come up with a proposal for, is strict type casts, so
      that this code can actually be written safely but still concisely.<br=
>
    </p>
    <p><br>
    </p>
    <p>Regards,<br>
    </p>
    <pre cols=3D"72">--=20
Rowan Tommins
[IMSoP]</pre>
  </div>

</blockquote></div></div>

--000000000000afc31d061b62d591--