Re: [VOTE][RFC] Scalar Type Hinting with Cast
| From: | Andrea Faulds | Date: | Sun, 14 Sep 2014 16:17:16 +0000 |
| Subject: | Re: [VOTE][RFC] Scalar Type Hinting with Cast | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-77186@lists.php.net to get a copy of this message | ||
On 14 Sep 2014, at 17:09, Andrey Andreev <narf@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/