[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-12-08 Thread Lucas Werkmeister
I uploaded some Gerrit changes for the code sniffer: chain starts at change 865650 . Reviews welcome! With those changes combined, *fully* typed functions (all parameters + return type) and typed properties are allowed (but

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-11-16 Thread Lucas Werkmeister
What Timo writes sounds good to me. I don’t think we need to enforce removal of existing code blocks – that can happen gradually as the code is touched for other reasons instead. Regarding performance, I think we should limit micro-optimizations like omitting static types to code that we know is

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-11-15 Thread Krinkle
On Tue, 15 Nov 2022, at 11:41, Daniel Kinzler wrote: > Am 10.11.2022 um 03:08 schrieb Tim Starling: >> 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

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-11-15 Thread Daniel Kinzler
Am 10.11.2022 um 03:08 schrieb Tim Starling: 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

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-11-09 Thread Tim Starling
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

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-11-01 Thread Kosta Harlan
Daniel Kinzler writes: > Also there is the notable exception of the array type. Saying that something > is an array is generally insufficient, we > should say at least whether it’s a list or an associative array, and document > the type of the array elements or and/or > well-known keys. +1,

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-10-31 Thread Adam Wight
+1 to moving towards more type hints And just to expand on Amir's comment, giving a type hint for return values is usually safe because you can see exactly what types are possible, but parameter type hints can be dangerous unless you look at all usages of the function.  Nulls can be

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-10-30 Thread Amir Sarabadani
Hi, A great initiative, thank you! I am generally in favor of this proposal but just want to give a cautionary tale. It's a bit off-topic but important. Given that there is no actual enforcing mechanism for the documentation typehints, some of them have actually drifted from reality. I caused a

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-10-30 Thread Daniel Kinzler
Thank you for suggesting this! I agree that type declaration is preferable to type documentation, and that type documentation is often redundant if type declaration is present. However, we can't always use type declarations. For instance, union types are quite useful, since PHP doesn't have

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-10-28 Thread Lucas Werkmeister
> > We have already disabled some of these rules for new code in the Translate > extension (ref > > ) > Interesting – we do something similar in some Wikibase codebases (ref

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-10-28 Thread Bartosz Dziewoński
I agree, a lot of the doc comments become redundant when types are specified in type hints. Note that doc comments for properties are actually not required, as far as I can tell – you could replace: /** @var LinkRenderer */ private $linkRenderer; …with: private LinkRenderer

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-10-28 Thread Thiemo Kreuz
100% agree. Comments that do nothing but repeat what the code already says serve no purpose¹. I regularly remove these but can't when it means PHPCS starts complaining. Typical example: /** * @param User $user * @param array $rights * @return bool */ public function isAllowed( User $user,

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

2022-10-28 Thread Niklas Laxström
pe 28. lokak. 2022 klo 17.04 Lucas Werkmeister ( lucas.werkmeis...@wikimedia.de) kirjoitti: > In my opinion, MediaWiki’s PHPCS ruleset feels largely rooted in an older > version of PHP, where static type declarations (formerly known as “type > hints”) did not exist. As we move towards more modern