Re: Concept: Custom Type Hinting
| From: | Andrea Faulds | Date: | Thu, 02 Oct 2014 23:49:40 +0000 |
| Subject: | Re: Concept: Custom Type Hinting | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-77752@lists.php.net to get a copy of this message | ||
On 2 Oct 2014, at 19:33, Dominic Grostate <codekestrel@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/