PHPStan reports "Property stdClassList::$classes (array<int, stdClass>) does not accept array<int|string, stdClass>." but I would expect that $classes will always be array<int, stdClass> without any string-keys
@heiglandreas@phpstan you can break many things at runtime when not respecting PHPStan annotations 😛
Adding the no-named-arguments annotation will at least prevent explicit calls in your codebase when SA is enabled.
But the main issue is that one might actually want to use named arguments. But then the variadic contains the "remaining" stuff and that should just be a list.
Apart from that the no-named-arguments annotation declares that the function will not receive named arguments. But that is on the caller to decide.
@bcremer@dkreuer was thinking about a #[VariadicList] attribute that could be used to autmatically apply an array_values` to the content of the array before passing it to the function body.
@heiglandreas@phpstan I added it before the assignment in the constructor, that seemed to work. But I saw your toot regarding named arguments so that's probably not the ideal solution anyway :P
@theseer Yeah. But at that point it should not be an associative array any more.
I get that the associative array makes sense for named parameters. But this one is for all the other - non-named - parameters.
/cc @shochdoerfer@phpstan
@shochdoerfer@heiglandreas@phpstan The variadic doesn't care. All phpstan is telling you that if you do new StdClassList( ...['a' => new StdClass]); the key "a" is kept in the params array. And does not magically turn into an int. If you'd do $this->classes = array_values($classes); the problem is gone.
Nevertheless should PHP itself convert the content of the variadic (after extracting all the named parameters) into a list as anything else doesn'T make sense. When I pass items as function arguments I do not have any string keys.
That has nothing to do with PHPStan at that point.
@heiglandreas PHP can't know if a key you pass without a named param match is because you want to ignore it or it was a mistake, e.g a typo in the key. So it emits an error, and it makes sense.
I blame implementation of named parameters... that was so problematic. Named params should have been opt-in. The person declaring the function should have been able to enable named params at function level. Native functions/methods would have been all opted-in.
@gmazzap Currently no error is thrown at all. The array is passed as-is.
In this example https://3v4l.org/kogWt the parameter that was used for a named parameter is removed from the variadic array but the array still contains string keys that are no longer of any use here.
Yes: Opt-In via i.e. #[VariadicArray] might have been a better solution.
Yes, an error is thrown when one tries to overwrite an already passed argument via the named parameters. But that is totally unrelated to the Array/List issue after checking for the named arguments.
Add comment