On 2 Oct 2014, at 19:33, Dominic Grostate <codekest...@googlemail.com> wrote:
> My concept can be found here: > https://gist.github.com/orolyn/9ff0756b3cb3cdfe454b I actually have a similar idea I’d like to propose (I’d write a patch first, it’s on my list of things to do), though it has scalar type hints only as a fringe benefit. I don’t think I like this proposal, though. I don’t think we should introduce a new `typehint` keyword. PHP already has too many reserved words. There are some that aren’t reserved which I’d like to reserve (int, float, string and bool), but I don’t think we should make typehint such a word. Functions in PHP cannot be autoloaded, so this would be quite inconvenient to use. Will people bother adding an include to every file merely to use typehints? Or are typehints classes, in which case, why not simply define them as a class rather than adding a new keyword? Or are they are new kind of autoloaded thing? As Johannes mentioned, this would require a function call every time an argument is passed. Unlike, say, auto boxing, once validated, you will still need to validate it again for each call. The performance impact isn’t so good. How does this handle references, and how does it handle null? How is inheritance/interface compatibility dealt with? Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
