Hi, > On 12 Feb 2015, at 07:05, Pavel Kouřil <pajou...@gmail.com> wrote: > > On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds <a...@ajf.me> wrote: >> >> A number (or numeric, or num, or some other name) type hint is something I >> plan to propose in a future, follow-up RFC. >> > > wouldn't polymorphism (via method overloading) solve the use cases and > be much more useful in the long run than introducing a something > that's not a type into type hints?
PHP already has polymorphism through its dynamic typing. I don’t see method overloading happening any time soon. We have optional parameters and dynamic typing, which all but eliminate the main needs for overloading. We’re a weakly-typed language, so overloading on scalar types might cause unpredictable behaviour (with strict types you’d get an error sometimes, and that’s fine - but calling an entirely different function? Now that’s different.) There’s also the question of how, or if at all, method overloading could interact with our optional parameters and dynamic typing. Finally, overloading can lead to really poor API design: it’s not that uncommon in some languages to see 20 different function definitions with overlapping and non-comprehensive subsets of a method’s behaviour, that are distinguished only by parameter types. It’s one of my least favourite Java/C#/C++ features for that reason. In response to saying numbers are not a type: well, they are more of an abstract type which integer and float subclass. We already have internal facilities for converting to and from “numbers” alongside integers and floats, I don’t see why we can’t expose this to users. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
