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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
