@milo That wasn't an answer to my question - why can't I just do ->setTypeHint('ServerRequestInterface')
What if I refer to another class in the same namespace? Why overcomplicate things? Yes, it helps correctness I guess, but why not just warn about it instead of forcing it and ending with file containing something different than what I'd write by hand. It's hugely unintuitive and a usability hurdle. Case in point - I made a little CLI tool (php-class) for fast class skeleton creation. Used like: for C in X Y Z; do php-class $C -n V/P/NS -u 'A/B as BB' -m 'public function someFunc(BB $bb): ?BB' -o ./NS/; done
Or, rather, I'd like to use it that way - it contains a function parsing the method declaration, written with the idea of parsing what I'd write by hand in the .php file. See the problem? At present, it uses ->setTypeHint('BB') and the result is public function someFunc(\BB $bb): ?\BB. I can modify it to track uses and the current namespace, alright. But it looks like the php generator already tracks this, but only one way: 'use X\Y as Z; ...(X\Y $z...' -> '...(Z $z...' and 'namespace NS; ...(NS\C $c...' -> '...(C $c...'. So, a suggestion / feature request - check uses and leave alone type hints. Make this behavior optional with something like ->allowUnknownClasses(bool $uc) and trigger_error when such class encountered.