In some distant future it could be implemented in more natural way with classes for primitive types and automatic boxing/unboxing for primitive built-in types:
Php\Type\Object Php\Type\Scalar ⌊ Php\Type\String ⌊ Php\Type\Integer ⌊ Php\Type\Float ⌊ Php\Type\Boolean Php\Type\Array And it will be easy to typehint all scalars via common parent class: public function acceptsScalar(Scalar $scalarValue). But all scalar objects in this case should be implemented as immutable or should be passed as copy (like arrays). So, I would vote no for adding special scalar typehint without mapping it to the common class or interface, like iterable => Traversable, callable => Closure, etc Best regards, Alexander 2017-12-26 18:59 GMT+03:00 Andreas Heigl <andr...@heigl.org>: > Hey All. > > > Am 26.12.2017 um 14:38 schrieb Sebastian Bergmann <sebast...@php.net>: > > > >> Am 24.12.2017 um 15:34 schrieb Fleshgrinder: > >> I prepared a PR to add the `scalar` pseudo-type to PHP after the > >> discussions around adding a `mixed` pseudo-type. I strongly believe that > >> it makes sense to provide the most common primitive union types with > >> handy aliases even if we are going to add union types in the future to > PHP. > > > > Thank you, Richard, for working on this. > > > > I spent a lot of time this year introducing scalar type declarations into > > existing code bases. In quite a few cases I was not able to do so because > > the existing code works with parameters that can be of two or more scalar > > types. With PHP 7.2, I can only document this outside of the code using > > @param annotations (until the code has been refactored to work with only > > one parameter type). > > > > With a "scalar" type declaration I would not have to fall back to @param > > annotations and could express the type in actual syntax. > > Just a stupid question from someone that isn't following all the > discussions here. So forgive me if the question was already asked and > answered. > > What would be wrong with a "composed type hint"? Something like > int|float|double $numeric. Or array|Traversable $iterator? > > It would allow people to add "mixed" typehints without having to introduce > multiple typehints that combine different scalar typehints. And it could > even allow typehinting different Objects in one function. > > Yes, it allows people to shoot themselfes into their own feet. > > And I'd only allow that for parameter types and never ever for return > types. > > But it might be an idea. > > Cheers > > Andreas > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
