Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96115
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.51 as permitted sender)
To: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAF+90c-4CuwgJgBPXbYvEJ0W6k41CfP94Xs-ZyNkUzrecbTzvg@mail.gmail.com>
Message-ID: <efab191e-486f-04f7-7b9c-c2fb3820b183@gmail.com>
Date: Fri, 23 Sep 2016 12:45:47 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c-4CuwgJgBPXbYvEJ0W6k41CfP94Xs-ZyNkUzrecbTzvg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Namespace-scoped declares
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> The broader context of this proposal is to provide a simple and usable
> mechanism that will allow developers to opt-in to stricter language
> semantics on a per-library (or more specifically, per-namespace) basis,
> thus alleviating backwards compatibility and library interoperability
> concerns for such changes.

I don't think it's a good idea. Not only we'd have two language
semantics in one language - which is by itself very far from ideal - but
you'd have absolutely no way of knowing which semantics is active for
which file by just reading that file. You will have to consider all code
that could potentially run up to this point, and all code paths that
could have been taken, and could disable or enable strict context. It
could also mean that the same code could actually run with both models,
depending on the caller - which goes contrary to the whole point of
strict declaration. It's way worse than ini setting - at least ini
setting is supposed to be one for every install of the code and can't
change in runtime depending on code paths.

Moreover, this precludes any optimization decision from being made by
opcode cache and such - if the same file code can be run in both strict
and non-strict context, depending on what was executed before in the
same request, it is impossible to make any optimization decision on
per-file basis.

Moreover, this RFC clearly build an infrastructure for making more
semantic forks, eventually leading to the situation where reader of the
code has absolutely no idea, looking at the source of certain function,
what is actually the semantics of the language and the rules it will be
executed under. And neither, even worse, does the author of the code.

If that were localized by file, it'd be bad but one could grudgingly
tolerate it - you could scroll to the beginning of file and say "oh,
sigh, now we're in PHP with strict types, but lax objects, but strict
integers, but lax floats, but strict comparisons, but lax conditionals,
but strict argument counts! Now I understand what's going on if I only
keep in mind those 20 bits that are different in every file!". But after
delocalizing it, all hope is lost - you never know what the code in the
file actually means - because somebody could write code in completely
different file, maybe even JSON composer configuration or some other
config file you didn't even think to be able to change your language
semantics - and suddenly all the code works differently.

Or, for more fun, breaks differently. And you as code author have zero
control over it because of the wonders of shared mutable state which now
encompasses not only data but the very core of the language. Imagine how
fun it is if somebody's action in different code module wouldn't just
mess up some data - it would actually break your code by changing
language semantics for your code!

I don't think it is a good way to write a maintainable software.
-- 
Stas Malyshev
smalyshev@gmail.com