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 <ayg(a)aryeh.name> wrote:
On Tue, Aug 27, 2019 at 11:53 PM Daimona
<daimona.wiki(a)gmail.com> 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
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l