Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106715
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=iIOtlw2oWNHUP17FE0/uHHsyvh5s12HgXIjZgUyuPHehqLCmj474Z2wBPJanFm
	H8SoxvcxBAtgjhUb+DkfYz1txcHyd4uIgbZAUrNur3keNSfgUO5Nmu6tbPu1IpZF
	HPbbwVJHsJEnjw/nLrpeZDpdoeD3txOXqE9AhlW8sDPHk=;
MIME-Version: 1.0
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
In-Reply-To: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
Date: Wed, 28 Aug 2019 13:40:47 +0300
Message-ID: <CAJHtznyadHb5_RgjddnPiyeWXtLQyp2CDK=ix=BiEd+DEUHqLg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007ebf6205912b0667"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: zeev@php.net (Zeev Suraski)

--0000000000007ebf6205912b0667
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> I think it's time to take a look at our existing warnings & notices in the
> engine, and think about whether their current classification is still
> appropriate. Error conditions like "undefined variable" only generating a
> notice is really quite mind-boggling.
>
> I've prepared an RFC with some suggested classifications, though there's
> room for bikeshedding here...
>
> https://wiki.php.net/rfc/engine_warnings


Specifically on undefined variables, the way we deal with them has little
to do with register_globals.  It's behavior you can find in other dynamic
languages (e.g. Perl), and allows for certain code patterns (which rely on
the automatic creation of a variable whenever it's used in write context,
and on a default known-in-advance value in case it's used in a read
context).  It's fine not to like this behavior or the code patterns that
commonly rely on it (e.g., @$foo++), but it's intentional and isn't related
to any historical reasons.


I think many (if not all) of your proposals make sense, but most of them
make sense as an opt-in - perhaps using something similar to Perl's strict
mode (which incidentally, changes the way the language treats undefined
variables in exactly the same way).  This would also provide a future-proof
solution for additional similarly-themed proposals (such as strict ops,
etc.).


Zeev

--0000000000007ebf6205912b0667--