On 29/10/22 01:03, Lucas Werkmeister wrote:
Proposition 2: *Adding types as static types is generally
preferable.* Unlike doc comments, static types are checked at
runtime and thus guaranteed to be correct (as long as the code runs
at all); the small runtime cost should be partially offset by
performance improvements in newer PHP versions, and otherwise
considered to be worth it. New code should generally include static
types where possible, and existing code may have static types added
as part of other work on it. I believe this describes our current
development practice as MediaWiki developers.
I generally don't add return type declarations to methods that I add,
and I have pushed back on CR requests to add them, except when the
exception is reachable, i.e. a TypeError may actually be thrown if the
class is misused by an external caller. The reasons for this are
clutter and performance.
Clutter, because it's redundant to add a return type declaration when
the return type is already in the doc comment. If we stop requiring
doc comments as you propose, then fine, add a return type declaration
to methods with no doc comment. But if there is a doc comment, an
additional return type declaration just pads out the file for no reason.
The performance impact is measurable for hot functions. In gerrit
820244 <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/820244> I
removed parameter type declarations from a private method for a
benchmark improvement of 2%.
I would prefer to return the performance benefits of newer PHP
versions to our users, rather than to fully consume them ourselves by
increasing abstraction.
-- Tim Starling