Hi,
On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski <z...@zend.com> wrote:
>> -----Original Message-----
>> From: François Laupretre [mailto:franc...@php.net]
>> Sent: Tuesday, February 17, 2015 2:58 PM
>> To: 'Sara Golemon'; 'Zeev Suraski'
>> Cc: 'PHP internals'
>> Subject: RE: [PHP-DEV] Reviving scalar type hints
>>
>> 2. It is not not about being lossless or not. People expect bool -> int to
>> be
>> disabled, for example, and it is not lossless.
>>
>> 3. It is more a question of finding a consensus about conversions which
>> don't
>> make sense, and disabling them. Examples include bool conversion to any
>> other type and, of course, disabling trailing chars in numeric strings.
>
> I agree. It's more of a question of eliminating potentially dangerous
> conversions than just being lossless.
>
Agreed as well. However, while bool -> int conversion one of the
reasons why many people want strict type-hints, it also often makes
sense and is quite widespread. There's no silver bullet for that
problem.
>> 4. Once this is done, 99% of strict type proponents already said they
>> would
>> be OK with the so-called (not so) weak mode, making it possible to get rid
>> of
>> this far from perfect two-mode mechanism (actually, this two-mode
>> approach more and more reminds me a great idea about bringing
>> transparent Unicode support in PHP).
>
> Even though that's not what I meant when I sent my proposal in the morning,
> I've been wondering about the same thing (also with the feedback from
> Dmitry). Can go an extra step from both directions, and come up with a rule
> set that is stricter than the currently proposed weak hinting, but not as
> strict as the currently proposed strict hinting?
> Key challenge I see with that is that scalar type hinting would go farther
> apart from our implicit casting rules. However, the current RFC already
> aligned with ZPP as opposed to implicit casting rules (e.g. by rejecting
> "Apple" as an int). Choosing between that and having two separate modes, I
> think that's the better option.
>
I don't think it has 99% support, but surely better than the dual-mode
approach indeed.
But is it the best solution? The dual-mode approach was suggested
because there is need and demand for *two* kinds of type-hinting. Most
of the controversy and criticism came from the fact that introduces a
switchable mode, while most of the praise received was due to somebody
finally proposing *both* solutions at the same time.
>> > * Exclude internal functions from the strict switch. (Perhaps have a
>> > separate switch for internal functions at a later date)
>>
>> This would make the feature inconsistent from an end user's pov.
>>
>> If a user enables strict mode, he assumes strict checks for every function
>> he
>> calls. *We* know that userspace and internal functions use different
>> mechanisms, but the end user doesn't have to know. From his pov, a
>> function
>> is a function.
>
> I think that practically speaking, that is incorrect, at least from my
> experience with PHP developers. They do differentiate between built-in
> functions and userland functions. There are some fundamental differences
> between the two (being able to find their code, step into them in a
> debugger, find docs on php.net, etc.).
> As I mentioned earlier, the fundamental difference between built-in
> functions and userland functions in the context of our discussion is that if
> we introduce userland type hints, nothing happens before people change their
> code, and make (hopefully) informed decisions about what type hints to add,
> if any. No such luck with built-in functions, which have type information
> associated, built collectively over the last two decades. As Rasmus
> demonstrated, flipping that switch on for built-in functions results in a
> lot of work to 'clean' the code up, but you end up with having code that's
> not necessarily any better.
Complely agree with that statement. I tried to explain the same thing
multiple times already ... unfortunately with no success.
> That said, it's quite possible that the
> situation will be much improved if & when we implement the less-strict rules
> we're proposing here, which would accept "32" as an integer or 37 as a
> float.
>
That might work, if we're indeed looking for a compromise.
> If we still see that employing the strict(er) rules is very noisy with
> internal functions, a more appropriate option may be introducing new types
> into ZPP, that would correspond to the new rules we introduce in the
> userland type hints, and requiring extension authors to explicitly move to
> them where they believe it's appropriate. That will allow extension authors
> to make their choice regarding their APIs, similarly to the process that
> will happen in userland.
>
And that brings us back to square one ... Expose only 1 tool to
userland, but then give two options to the much less-populated crowd
of extension developers. That doesn't make sense to me.
>> So, from all these arguments, I now think that strict types, as defined in
>> 0.3,
>> are not the best solution.
>>
>> > With option to introduce features such as the following at a later date:
>> >
>> > * Union types (e.g. function foo((int | float) $value): (bool |
>> > string) { ... })
>> > * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as
>> > standard (like numeric), others user-definable)
>>
>> As I told Zeev, union types can be kept for the future if we don't go the
>> nullable road, as it would be too confusing making 'string|null' and
>> '?string'
>> synonyms.
>
> I think we all agree about that.
>
Yep.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
