On 14 Sep 2014, at 17:09, Andrey Andreev <n...@devilix.net> wrote: > I'm aware of that, hence why I said 'php-internals' to refer to the > mailing list. Again, userland devs don't care about that - PHP is > their language and they only care how we/they interact with it, not > what happens under the hood.
Yes. Internal functions are used by userland developers. Userland developers *do* care about internal functions. If we get rid of explode() or json_decode() tomorrow, userland developers *will* complain. Perhaps I should explain what an “internal function” is in PHP parlance. An internal function is one which is exposed to userland, but is implemented in C via an extension, rather than in PHP. Examples include literally every function in PHP’s documentation. >>> Speaking strictly from a userland perspective, using that same syntax >>> for something different will be inconsistent and will cause confusion. >>> That another syntax could be used for strict typing in the future is >>> just not a serious thing to say. >> >> Why is it "not a serious thing to say”? I don’t understand. > > Because it's obvious that you're not even thinking of that as a > possibility. What would that syntax be? "function foo([int] $bar)" ? function foo(int! $bar) Though it’s true, I don’t want to have them. > As I already said, we already have and use a syntax for strict typing. > This RFC uses that same syntax for something different and that's > wrong, hence why the RFC should be changed, not the other way around. I know you have a problem with using similar syntax for non-strict typing, but I don’t. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
