Hi,
On Sun, Sep 14, 2014 at 6:09 PM, Andrea Faulds <ajf@ajf.me> wrote:
>
> On 14 Sep 2014, at 15:56, Andrey Andreev <narf@devilix.net> wrote:
>
>> It seems a bit political ... A lot of people want either strict type
>> hints or type casting hints, but because the people on this list can't
>> get to agree on any of the two, this RFC tries to make a compromise
>> that, IMO, satisfies nobody. It's done not for the benefit of
>> everybody, but just so we can say that PHP has "scalar type hints".
>> I've said this in the RFC discussion thread: In order to satisfy both
>> sides, instead of arguing which is the one and true way, just
>> implement both.
>
> I’m not sure it satisfies nobody. I realise a lot of people would prefer strict types, but plenty are still in favour of this as a compromise:
>
> http://strawpoll.me/2463199/r - Might not be representative, but I held a poll on Twitter and StackOverflow. There are the results. 67 would vote in favour of strict hints (à la Hack), and 36 would vote in favour of this RFC, with only 5 willing to vote against it, versus 10 voting against strict hints. Note that the options aren’t mutually exclusive.
So, basically ... the poll shows nothing. :)
I was actually looking for that link (I took part in the poll), but
couldn't find it.
>> That is also why I suggested altering the proposed syntax here from:
>>
>> function foo(int $bar)
>>
>> to:
>>
>> function foo((int) $bar)
>
> But it’s not a cast. Such a syntax would be misleading. You would reasonably expect the following two functions to be equivalent:
>
> function foo($bar) { $bar = (int)$bar; }
> function foo((int) $bar) { }
>
> Yet they are not equivalent at all.
They are not equivalent, because of the different rules that you're
proposing here, but it is a cast. And the fact that with this RFC
_both_ would mean some kind of cast is happening, is simply bad.
>> Whether it applies more strict rules or not, this RFC is clearly about
>> type _casting_ hints, while the used syntax has so far only been used
>> for strict type hints.
>
> Well, we haven’t had any scalar hints so far. It’s also worth noting that the documentation for PHP uses this style even though internal functions are not strict. Furthermore, scalar types in PHP are fundamentally different from non-scalar types. We do not have weak typing for non-scalars: there are no implicit casts between non-scalar types. However, we implicitly convert and juggle the scalar types all the time.
... 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.
>> I know some would argue that this is a side
>> effect because you can't cast to a specific class type, but that's not
>> the point - the result is a strict type hint and that's what people
>> are used to. This is both inconsistent AND prevents PHP from having
>> strict scalar type hints in the future (because of the used syntax).
>
> Strict hints would still be possible with different syntax. However, I’m not sure they’re a good idea. Strict hints would be abandoning PHP’s weakly-typed nature, and would segregate userland functions into two kinds: strict and non-strict. I also don’t expect that would pass internals anyway.
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.
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.
As for the language's nature/philosophy/direction/whatever, I had
something written about that, but chose to discard it in order to
avoid that "discussion". Everybody is tired of talking about that.
> I don’t think permitting multiple options is really the way forward, that sounds like the worst of both worlds.
You can't say it's the worst of both worlds when you have both worlds
in their entirety. And most importantly, they have always been two
separate worlds because they just don't make sense otherwise. I could
argue that this compromise RFC here is a mistake exactly because it is
trying to mix them.
Cheers,
Andrey.
