Well, changing something in core and breaking a production extenison doing something silly can't be waived away with "it's the extension's problem" ;)
I mostly use "final" to enforce a delegation pattern, where only certain key bits of functionality should be filled in by subclasses. It mostly comes out of years and years of bad experience with core and extension code subclassing things in annoying ways that inevitably have to be cleaned up as a side-task to getting some other feature/refactoring patch to pass CI. It's a clear way to both document and enforce subclass implementation points. The only reason not to use it is for tests, and I have removed "final" before (placed in BagOStuff) when I couldn't come up with another workaround. Interfaces will not work well for protected methods that need to be overriden and called by an abstract base class. If no PHP/PHPUnit fix is coming soon, as a practical matter, I'm sure some other alternative documentation and naming style pattern could be standardized so that people actually follow it and don't make annoying and fragile dependencies. On Wed, Aug 28, 2019 at 12:30 AM Aryeh Gregor <[email protected]> wrote: > On Tue, Aug 27, 2019 at 11:53 PM Daimona <[email protected]> wrote: > > Personally, I don't like these limitations in PHPUnit and the like. IMHO, > > they should never be a reason for changing good code. > > I don't like these limitations either, but testing is an integral part > of development, and we need to code in a way that facilitates testing. > In each case we need to make a cost-benefit analysis about what's best > for the project. The question is whether there's any benefit to using > final that outweighs the cost to testability. > > > And sometimes, methods have to be final. > > Why do methods ever "have" to be final? Someone who installs an > extension accepts that they get whatever behavior changes the > extension makes. If the extension does something we don't want it to, > it will either work or not, but that's the extension's problem. > > This is exactly the question: why do we ever want methods to be final? > Is there actually any benefit that outweighs the problems for testing? > > > Anyway, some time ago I came across [1], which allows mocking final > methods > > and classes. IIRC, it does that by removing the `final` keywords from the > > tokenized PHP code. I don't know how well it works, nor if it could > degrade > > performance, but if it doesn't we could bring it in via composer. > > That would be a nice solution if it works well. If someone wants to > volunteer to try to get it working, then we won't need to have this > discussion. But until someone does, the question remains. > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- -Aaron _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
