Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82964
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1913e09d7f52541901d8574d2080a63f@mail.gmail.com>
References: <011801d04a07$83ab1c00$8b015400$@php.net>
	<CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>
	<016f01d04a3a$e9183220$bb489660$@php.net>
	<CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>
	<d8031ce52e9965c789887e8f7b687a4e@mail.gmail.com>
	<CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>
	<022801d04ab1$4a0c47d0$de24d770$@php.net>
	<1913e09d7f52541901d8574d2080a63f@mail.gmail.com>
Date: Tue, 17 Feb 2015 16:49:22 +0200
Message-ID: <CAPhkiZy+3qzFSN4Kfx42jrZVukE2zLeGzB3Yez5=o9FhGnxiRg@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: francois@php.net, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: narf@devilix.net (Andrey Andreev)

Hi,

On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski <zeev@zend.com> wrote:
>> -----Original Message-----
>> From: Fran=C3=A7ois Laupretre [mailto:francois@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 r=
id
>> 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 mornin=
g,
> 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 r=
ule
> 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 farthe=
r
> 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 functi=
on
>> 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 th=
eir
> code, and make (hopefully) informed decisions about what type hints to ad=
d,
> if any.  No such luck with built-in functions, which have type informatio=
n
> 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 ru=
les
> 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 type=
s
> into ZPP, that would correspond to the new rules we introduce in the
> userland type hints, and requiring extension authors to explicitly move t=
o
> them where they believe it's appropriate.  That will allow extension auth=
ors
> 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 dat=
e:
>> >
>> > * 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 th=
e
>> nullable road, as it would be too confusing making 'string|null' and
>> '?string'
>> synonyms.
>
> I think we all agree about that.
>

Yep.

Cheers,
Andrey.