Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106787
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=pIl6p32nqEKdZQx0SnFXLF3Yv3rkHrMETHkx8lntyduk50trBfHit6xfRPnvQc
	0qHN0nXQ/yNUlnSvaooMhc2TjzY/5UM7KULG69XT9vbYpY1VbcvmTgU0+56ChDer
	SJgAuROB5Xa0AOKcLl53RCbZiT7ks4iACV6r85XtNUb4Y=;
MIME-Version: 1.0
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com> <CAKuGYLQC2z+GmOgbqxFWbAGS6B2z=mXTp72c6Be53ju4D6pNRw@mail.gmail.com> <CAJHtznxgkUFZ2os5Hx5rYmFCrATJ+LTOovK6W4J1cDw6oo45=w@mail.gmail.com> <CAKuGYLQfg8CQOORWTO57Cfk92oM3DNmw0h9wt3jP9gSUCx+QWg@mail.gmail.com> <CAJHtznw1POVOtK656fWn+Vdj94RnHWmZ9A5rEHoWjiXXod=Piw@mail.gmail.com> <CAKuGYLR6j173SKUxR0gXnCARZ-Lg4mmZyOLJYD8hRfsKnp9CfQ@mail.gmail.com>
In-Reply-To: <CAKuGYLR6j173SKUxR0gXnCARZ-Lg4mmZyOLJYD8hRfsKnp9CfQ@mail.gmail.com>
Date: Thu, 29 Aug 2019 08:51:52 +0300
Message-ID: <CAJHtznzwcPEYQLRsu1GxEMK_GfYG-NHt2j7te_thUOcMX6FB5Q@mail.gmail.com>
To: Matthew Brown <matthewmatthew@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f66d0805913b1a1d"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: zeev@php.net (Zeev Suraski)

--000000000000f66d0805913b1a1d
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 28, 2019 at 10:28 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> Javascript has treated undefined variables as a catchable exceptions since
> (I think?) forever. Perl is the only other language I know that allows them.
>

That isn't the point (I alluded to the fact that JS dealt with something
*similar* but not quite the same in my first mention of it).  The point is
that when they wanted to make behavior around variables strict*er* than
what it was originally, they didn't simply change it - they added an opt-in
strict mode.

I've written code in a lot of different languages. Many of those languages
> (most notably Standard ML) forced me to think about how exactly data flowed
> through my program. PHP, on the other hand, doesn't demand anything like as
> much work. This means its developers often don't improve much either, which
> ultimately this harms the language's reputation as former PHP developers
> discover their bad habits don't translate well to other languages.
>
> With this change we can make it harder for people to write bad code, which
> I think will result in existing PHP users becoming better developers.
>

With this change we're taking away from people - including very informed
developers - the ability to use it as intended (one form of it that is).
There's a reason there's a wide selection of languages available, and that
different people have different language preferences.  Personally, I can't
stand ML - and I find myself a lot more productive in other languages.  But
I'm not going to campaign to change ML into something different because it
doesn't fit my programming/thinking style.

Granted - PHP is orders of magnitude more popular and widely used than ML,
and we need to figure out ways to make this huge audience content -
including many who aren't happy with its behavior (whether it's because
they made an uninformed decision choosing it, or because it wasn't their
choice at all, or because they actually do like the language and would be
happy to use it if only it had X, Y and Z).  But it shouldn't be at the
expense of others.  Exactly like Perl and JS did it when they decided to
offer a stricter execution model.

Zeev

--000000000000f66d0805913b1a1d--