rfc recursive return type definitions
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start with the recursive @return and @param examples in issue #9 and review the parser's existing type syntax. No file, test, or entry point is named. Done would require an agreed recursive type representation and corresponding parser behavior.
Written by the indexing model from the issue text.
Description
/**
* @return array<string, scalar|array<int, array<{{recursive definition is here}}>>>
*/
function DoThingWithNode(DOMNode $node) : array { /* do stuff here */ }
So I have this method that return an array with string keys whose values are either scalars or arrays with string keys whose values are either scalars or arrays with string keys whose values are either scalars with string keys..... etc.
If the definition stops at array, then one would just assume that phpstan et. al would determine that values at that level are "mixed" (or otherwise defined), which may be an undesirable effect.
One solution to the recursive @return/@param problem could be to define a class that encapsulates the recursion- i.e. class Thing extends ArrayObject & modify the return types to indicate scalar|Thing, but I'd be wanting to avoid class definitions.
A docblock-type solution would be to define a template/pattern tag so one could @thing foo array<string, scalar|array<string, {{@thing foo}}> , but I could foresee problems by virtue of it being a recursive solution to a recursive problem.
Thoughts?
p.s. the recursion here comes from the return type possibly containing arrays of the return type of the method, so maybe @return array<string, scalar|{{@method DoThingWithNode}}||{{@method DoSomeOtherThingWithNode}}> might be a solution by explicitly indicating the return values is built up from other methods ?
- Dominant language
- PHP
- Stars
- 1.5k
- Forks
- 78
- Avg merge
- 9h 5m
- Merged PRs (30d)
- 5
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from phpstan/phpdoc-parser
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
phpstan/phpdoc-parser#317 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
phpstan/phpdoc-parser#281 · 2 comments · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
phpstan/phpdoc-parser#271 · 1 comment · 1 reaction ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
phpstan/phpdoc-parser#219 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
phpstan/phpdoc-parser#178 · 1 comment ·
All issues in phpstan/phpdoc-parser
Similar issues
-
priority: p3
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
googleapis/librarian#7636 ·
-
0. Needs triage bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
nextcloud/fulltextsearch#1011 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
phpstan/phpstan-doctrine#794 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Automattic/static-site-importer#1767 ·