Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96137 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96219 invoked from network); 25 Sep 2016 17:29:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Sep 2016 17:29:12 -0000 X-Host-Fingerprint: 2.123.164.178 unknown Received: from [2.123.164.178] ([2.123.164.178:9439] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4A/79-11573-66908E75 for ; Sun, 25 Sep 2016 13:29:11 -0400 Message-ID: <4A.79.11573.66908E75@pb1.pair.com> To: internals@lists.php.net References: Date: Sun, 25 Sep 2016 18:29:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 2.123.164.178 Subject: Re: [PHP-DEV] [RFC] Namespace-scoped declares From: ajf@ajf.me (Andrea Faulds) Hi Stas, I agree with you on all of this. Stanislav Malyshev wrote: > 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. The strict_types declare was very deliberately made local to individual files. This means you can always know what mode you're working with by looking at the top of the file, you don't have to check anything external, and there's no potential ambiguity. I don't think the addition of one extra statement at the top of each file is really so burdensome (especially given it can be automated if desired) as to justify getting rid of the current clarity explicit declare()s give us. > 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. I similarly feel that a proliferation of semantic forks is not ideal. From my perspective, strict_types is an exceptional case where I thought it was worth the slight fragmentation, there wasn't a better way to achieve the same outcome, and it was important enough to take that risk. Generally, though, I think it is best to avoid making language changes optional. Furthermore, I agree with you that such forks become more confusing if you can't tell which ones are in use from the file you're in. Haskell, which has a large number of optional language features, notably recommends that you turn them on using a pragma in source files (akin to PHP's declare()) rather than compiler flags. It is interesting that one of the reasons suggested for implementing namespace-scoped declares is to enable more of these types of semantic forks. If having to add extra lines at the top of source files is a deterrent to adding more of them, I think that may actually be a feature of our current implementation, not a bug. Thnaks. -- Andrea Faulds https://ajf.me/