On Wed, 1 May 2019 at 00:56, Stanislav Malyshev smalyshev@gmail.com
wrote:Hi!
Worth noting another inconsistency here that we've missed. PHP 7.4 has
introduced many BC breaks actually already. Without this level of
problems:Exactly, without. There's a difference between removing an unmaintained
extension which is barely used and setting people up for displaying
their sources if they use slightly outdated libraries. And there's a
difference between explicitly making a decision and not even bothering
to discuss this mammoth of a BC break until the vote is finished. So to
me it's more like "elephant in the room" scenario - we've got a process
failure here. We are on the course to correct it, but it's a failure
nevertheless.It is a BC break nevertheless no matter how much time it takes to
change the code. The level of the impact cannot be measured like this.
Of course it can be. Scratch that - that's not one way to measure it, it's
the only sensible way to measure it.
The only way to look at this is a cost/benefit balance, and here, the cost
is considerably high, and the gain is virtually non-existent. All the
points the RFC mentions were known and factored in back in 1998, virtually
all of them are either mild or factually wrong - such as the simplication
of the parser (the parser is 100.000% oblivious to whether short tags are
enabled or not, and they're implemented in roughly 10 lines of code that
haven't changed for probably 15-20 years in the scanner).
For mostly everything else deprecated in 7.4 and 7.x in general - the cost
is typically very small - and often the gain is a lot more substantial. In
other cases, the reason of the deprecation is simply coming to terms with
reality - e.g. that a given extension isn't being actively maintained so we
can no longer support it.
There's no comparison between deprecating a basic building block that's
been with us since 1998 - that will be all over the place in code that uses
it (and there's plenty of that out there), with the deprecation or slight
mods that will be affecting a tiny fragment of the userbase.
I haven't seen code with short tags for such a long time now that this
is for me a problem on a scale of a fly.
This is precisely not the kind of thinking we should have here, and
what I was alluding to when I spoke about responsibility.
The fact you haven't seen code with short tags for a long time, means
exactly that - that you haven't seen code with short tags for a long time.
We can also build upon that, as well as feedback from others here and some
indicators and trends in PHP development - and extrapolate that you're not
an outlier here, and in fact, most folks who are at the top 10-20% - at
least - haven't been using short tags for a very long time, if ever. I
already said that I'm deep in that group as well.
However, that's just one part of the PHP world. And on internals, we're
supposed to care about the entire PHP world, including parts that are
severly underrepresented here but nonetheless exist and are very large.
There's TONS of PHP development going on behind closed doors, by developers
who probably couldn't care less about PSR's, code beauty and even
portability - given they're writing stuff for internal use. For others -
they may care more, but have to maintain other people's code that's been
working for ages - and they only have to do the minimal amount of work to
keep it working as new versions are installed.
As a project, we care *greatly *about people upgrading to the latest
version - primarily for security considerations. The top reasons to
upgrade, in my experience, have been (a) performance, and (b) security -
with features coming at a distant third. That is especially true for
legacy apps with little active development. Every BC break we add without
an excellent reason, means that needlessly - fewer people will be
upgrading, and those who would upgrade would do so on a longer time scale.
Because we've simply upgraded
all very very long time ago or in other words even never thought of
writing something in these tags anymore. Well, obviously this might be
for someone else a problem on a scale of an elephant, that I don't
know and probably won't understand fully. But, also at least now this
discussion and also RFC brought this thing out - short open tags
shouldn't be used anymore in any case. :) Because obviously a very
large number of people would like to have more clear definition of
what is opening PHP tag.
To be honest, I don't think it's something at the scale of an elephant for
the vast majority of folks. But I think that may be cow-sized for many.
The other side of the equation is that the benefit of removing it - is
barely even a fly. This deprecation brings virtually no value. The
cost/benefit balance weighs extremely against it. But you have to be
thinking about the folks that aren't here on internals or in the top tier
of PHP development in order to reach that conclusion.
Zeev