> > No, that's only what happens with mockery. The tool I found just strips > 'final' keywords from the PHP code - I believe, I still haven't looked at > the implementation.
As far as I can tell, it actually strips final tokens from *any* PHP file that’s read, including by application code. It seems to override the standard PHP handler for the file:// protocol, and rely on the fact that the PHP engine also uses that handler to read source code files. (Also, I think it only applies to .php files and not Apache-style .php.en files, but I guess that’s not a problem for us.) Am Mi., 28. Aug. 2019 um 16:49 Uhr schrieb Daimona <daimona.w...@gmail.com>: > >Subclassing should be very limited anyway, and even more limited across > module > >boundaries > > I agree, but it doesn't offer a strict guarantee. > > > which could even be enforced via static analysis. > > Why not just use final, then? > > > Method contracts should be enforced by compliance tests. When following > these principles, making > > methods and classes final has little benefit. > > Ideally, yes. But I don't think our codebase has enough tests for that. > > > Preventing mocking is however a pretty massive cost. > > Definitely yes. But making methods mockable while also keeping the > capability to use finals is even better IMHO. > > > Static code should only be used for pure functions. That's a very limited > use case. > > In theory, for sure. But I believe there are lots of occurrences in our > code where static methods are not pure functions. > > >> If you want to make sure that any subclass won't ever change the > >> implementation of a method, and thus all callers know what to expect > from > >> calling a final method. > >> I see finals as a sort of safeguard to help write better code, like e.g. > >> typehints. > > > >This should eb done by documenting contracts, and having tests ensure > compliance > >with these contracts. Final methods make callers rely on a specific > >implementation, which may still end up changing anyway. > > Two sides of a coin, I think. Each of them has its benefits and its > drawbacks, I'd say. > > >> IMHO this would be a perfect compromise. I've filed T231419 for that, > and I > >> also think that before discussing any further, we should try to see if > we > >> can install that tool. > > > >If I understand correctly, this would break as soon as the mock object > hits a > >type hint of instanceof check. That won't fly. > > No, that's only what happens with mockery. The tool I found just strips > 'final' keywords from the PHP code - I believe, I still haven't looked at > the implementation. > > > Il giorno mer 28 ago 2019 alle ore 16:29 Daniel Kinzler < > dkinz...@wikimedia.org> ha scritto: > > > I see no good use for final methods or classes. Or rather: I see a very > > limited > > benefit and a pretty massive cost. > > > > Subclassing should be very limited anyway, and even more limited across > > module > > boundaries, which could even be enforced via static analysis. Method > > contracts > > should be enforced by compliance tests. When following these principles, > > making > > methods and classes final has little benefit. Preventing mocking is > > however a > > pretty massive cost. > > > > I'd just remove the final markers. But maybe I'm overlooking > something?... > > > > Am 28.08.19 um 10:38 schrieb Daimona: > > >> 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. > > > > > > This is especially true for e.g. static methods, but here we'd be > > > renouncing to a possibly useful feature. > > > > Static code should only be used for pure functions. That's a very limited > > use case. > > > > >> Why do methods ever "have" to be final? > > > > > > If you want to make sure that any subclass won't ever change the > > > implementation of a method, and thus all callers know what to expect > from > > > calling a final method. > > > I see finals as a sort of safeguard to help write better code, like > e.g. > > > typehints. > > > > This should eb done by documenting contracts, and having tests ensure > > compliance > > with these contracts. Final methods make callers rely on a specific > > implementation, which may still end up changing anyway. > > > > > > > >> 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. > > > > > > IMHO this would be a perfect compromise. I've filed T231419 for that, > > and I > > > also think that before discussing any further, we should try to see if > we > > > can install that tool. > > > > If I understand correctly, this would break as soon as the mock object > > hits a > > type hint of instanceof check. That won't fly. > > > > > > -- > > Daniel Kinzler > > Principal Software Engineer, Core Platform > > Wikimedia Foundation > > > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > -- > https://meta.wikimedia.org/wiki/User:Daimona_Eaytoy > "Daimona" is not my real name -- he/him > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Lucas Werkmeister (he/er) Full Stack Developer Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30 219 158 26-0 https://wikimedia.de Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
