On Wed, May 1, 2019 at 3:19 AM Peter Kokot <peterko...@gmail.com> wrote:
> On Wed, 1 May 2019 at 00:56, Stanislav Malyshev <smalys...@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
