Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106071
MIME-Version: 1.0
References: <c-17aa9-jxbttytv-fj6p6s=1xtnjis@2.gethop.com> <6D1026FF-ECF1-4604-91A8-D290D37CC238@cschneid.com>
 <F6D115B8-0808-4EA6-B031-4CE61F3C5704@gmail.com> <CAG9XoMTJKFFF2hrxgjBy3_A+8MA6mbEg1_1o957fY6bP29G4Cw@mail.gmail.com>
 <F5FDFABD-2508-4D26-AE73-8829A068CA8F@cschneid.com> <CAG9XoMTb+g6g5gSFbvASeEcVj5N4crxgE1Exo120hJZLXRtwKQ@mail.gmail.com>
In-Reply-To: <CAG9XoMTb+g6g5gSFbvASeEcVj5N4crxgE1Exo120hJZLXRtwKQ@mail.gmail.com>
Date: Wed, 26 Jun 2019 12:00:18 +0100
Message-ID: <CALKiJKrX5=1a+aGa0arr+1LufKiA8mrCg5PGQsG=o2=ou4xpeg@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000fb29a058c37f48d"
Subject: Re: [PHP-DEV] [RFC] Strict operators directive
From: rowan.collins@gmail.com (Rowan Collins)

--0000000000000fb29a058c37f48d
Content-Type: text/plain; charset="UTF-8"

On Wed, 26 Jun 2019 at 10:36, Benjamin Morel <benjamin.morel@gmail.com>
wrote:

> Oh, I see. You mean that only replacing some of the current results with
> TypeErrors would be acceptable; returning a different value would not.
> This makes a lot of sense, but once again prevents the language from slowly
> moving towards something different (and better), leaving it stuck in its
> legacy forever.
>


If we're talking about combining operator overloading and type juggling in
the way that JS does it, I would definitely debate whether that's "better".
It leads to the weird circular situation where to know what an operator
means, you have to look at the types; but to know how the types will be
interpreted, you need to know what the operator means.

Perl is a notable contrast: the types of operands are deduced based on the
operator, but there are different operators to force them to different
types. So `23 < 4` and `"23" < "4"` are both numeric comparisons, so return
false; but `23 lt 4` and `"23" lt "4"` do string comparisons, and return
true. That way the user's intent is clear, but you don't have to manually
cast values or remember how different combinations will be interpreted.



> I'm starting to believe that a joint effort to fork PHP if the only way out
>


If what you want is a fork of PHP with stronger typing, then take a look at
Hack https://hacklang.org/


Regards,
-- 
Rowan Collins
[IMSoP]

--0000000000000fb29a058c37f48d--