On Sat, Aug 10, 2019 at 12:37 PM Andrea Faulds <a...@ajf.me> wrote: > Hi Zeev, > > As the person who initially proposed and implemented strict_types, I > think this is heading in the wrong direction. Perhaps that directive was > a mistake, if it will lead to so many attempts inspired by it to > fragment the language, including this one. Personally, I don't actually > want a language like C++ or Java. PHP's flexibility is great, and I > think splitting the language means going in a direction where you are > forced to have everything be strict or nothing be. PHP++ sounds like > Hack, but in mainline. I think it'll end up a mess in the long term. >
Hi Andrea, I really appreciate your point of view on this. I'd love to better understand what you think we should do when translating this point of view into action. Specifically - if we go in the direction of Editions, which - as far as I can tell - has the potential to split the userbase (de-facto) at least as much if not more - would you see this as a bad direction? Nikita pointed out that there are several strategies to introduce compatibility-breaking elements. The precedent that we introduced with strict_types, is to provide granular control at the feature level. Granted, we only did one of those so far - but it's of course a possibility to go on adding additional ones (such as strict_variable_declaration, strict_ops, etc.). The other option proposed is to have editions - which are collections of such changes, that come as a unified package - you can't pick and choose what you like or dislike, it's all or nothing The 3rd option that I proposed, is to have the equivalent of just two editions - we could call them 'classic' and 'strict' - that like editions, users will be able to choose from on a per-file or per-package basis. I *think* most of us will agree that option #1 isn't a very good one. It's by far the most flexible one - but it's also the messiest one. It's also arguably more complex to maintain, as you have to make sure each feature is conceptually consistent with each other feature in both of its mode (on/off), and also that each feature actually *works* with the other feature in both of its modes in terms of implementation, if there's any interaction between the two. I think most folks would agree that Editions is a superior idea. You group several changes together, and you have a new, consistent dialect of the language that users can opt into. It's by definition a lot less flexible, but flexibility isn't always a good thing. It's easier to maintain, easier to explain, provides fewer permutations of testing need to happen - and reduces the cognitive load when reading code. In terms of what we sacrifice - we don't sacrifice much - because as we come to evaluate the wants and needs of the userbase - it seems that the same folks that would want strict_types, would be the ones that want strict_ops and strict_variable_declarations. In my mind, Editions -> per-feature-control is similar to P++ -> Editions: - It's less flexible, but much like that's not a negative thing with Editions - it's not a negative thing here either. We won't have to support PHP2020 in a version that we'd release in 2023. Someone committing to P++ will be getting the new features (and compatibility changes) as they upgrade - precisely as folks who upgrade PHP today do, without having to (or being able to for that matter) opt-in or out. The motivation that everyone has to keep current (for stability/security reasons) will continue to be a driving force for folks to take the trouble to upgrade. They'd have the ~2 years of maintenance time of the previous version to take the time to upgrade - but over a long enough timescale, we'd have just two flavors - not N. - Psychologically, it allows us to introduce more compatibility breaks from the get-go - instead of rolling them out gradually over time. That is also a good thing. Much like PHP 5 (that introduced a completely different object model) kickstarted the development of brand new frameworks (Symfony, Zend Framework, others) - I'd expect there to be P++ frameworks that would spring to life. It's a lot more sensible to give them solid grounds upon which they can build the framework (or app) - and not tell them that them that if they'd want to keep current in 2025 - they'd be likely to have to roll out another rewrite. - Vision-wise, it allows us to lay out a clear, consistent vision for P++, and say how we think it will differ from PHP. We don't have to deliver on it right away - it will still be helpful to users to know what they should expect from PHP, what they should expect from P++ - and allow them to choose which one to focus on. It'll also help us in internals@ discussions - it'll usually be fairly clear what goes where - making discussions a lot less contentious. - Marketing-wise, it has clear advantages, even if many folks here don't want to evaluate that angle. P++ is not radically different from the Editions idea. It's quite similar, with a different roll-out strategy - and it opts to make a clear statement on the long term viability of dynamic PHP. Regarding splitting the userbase - I think we need to face reality. Our userbase is already soft-split, and as we introduce more and more optional-strict elements - this soft-split will grow larger (although I still think it'll remain soft - I don't think it'll descent into an "us vs. them" level). Since we're considering the introduction of more and more compatibility-breaking ever-stricter changes as a given (so many, in fact, that the key implementation challenge with P++ appears to be our ability to deliver all of them in a reasonable 2-3 year timeframe (!)) - we need to ask ourselves what that would mean in practice. It's clear that at least for some folks - that means that the language gradually evolves in that direction - slowly but surely leaving its dynamic nature behind and allowing it (or forcing it) to die. I'm hoping that the vast majority of folks here understand that this isn't a viable option, and I think we need to send a clear message to everyone (particularly the pro-dynamic crowd) that this isn't in store for them. At the same time, we need to figure out how we are going to manage the growing distance between dynamic PHP and the new one that we're working to create. If we insist on keeping our language unified as we introduce these changes - do you see a way to do that that is not a zero-sum game? Thanks again for your feedback, Zeev
