Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast

On Sun, Sep 14, 2014 at 6:47 PM, Andrea Faulds <[email protected]> wrote:
>
> On 14 Sep 2014, at 16:40, Andrey Andreev <[email protected]> wrote:
>
>> ... and I responded to this in the next paragraph. Userland doesn't
>> case about internal differences, that's why they're called internal
>> and why people outside of php-internals have for so long been puzzled
>> why we only have array and object type hints.
>
> "Internal functions” refers to functions from extensions. It has no relation to internal*s*, the mailing list.

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. Imagine for a moment that you've never
been involved in the development of PHP itself and you'll see how what
I say makes a lot of sense.

>> That's exactly what I'm talking about ... we already have a syntax for
>> strict typing, (and I want to put an emphais on this) *regardless of
>> the reasons why, we do have strict type hints*. I don't understand why
>> everybody is pretending that PHP doesn't have that feature just
>> because we're talking about scalars here.
>
> Nobody’s arguing we don’t already have strict type hints. I’m arguing strict hints don’t make sense for scalars. Note that we document strict (array, object) parameter types and non-strict (scalar) parameter types in the same way in our documentation.

And because you don't think it makes sense (and that might mean you
don't think it _now_), you're ignoring it. That's also a reason why
the documentation is done that way - nobody has thought of writing it
differently, because they didn't have to. The docs can always be
updated, but once the language changes, there's no going back.

>> 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)" ?

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.

>> You can't say it's the worst of both worlds when you have both worlds
>> in their entirety.
>
> No, you can. Allowing both options can be “the worst of both worlds”. This is just a trivial matter of semantics, though.

I'll ... just say that it's also the best of both worlds and agree to
disagree, I think you got the idea.

>> And most importantly, they have always been two
>> separate worlds because they just don't make sense otherwise.
>
> Have they? We already mix strict and non-strict typing in PHP. Functions taking objects, internal or not, will error if you pass the wrong type of object. Internal functions taking scalars will not error and instead cast, at least most of the time.

I already noted multiple times that I'm talking as a userland
developer and that no userland developer (generally speaking, of
course) cares about internal functions.

Cheers,
Andrey.