Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82971
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.181 as permitted sender)
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>
 <CAPhkiZy+3qzFSN4Kfx42jrZVukE2zLeGzB3Yez5=o9FhGnxiRg@mail.gmail.com>
In-Reply-To: <CAPhkiZy+3qzFSN4Kfx42jrZVukE2zLeGzB3Yez5=o9FhGnxiRg@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQGD0sLDaA+/0NIeBlQhQC5OtPA/xwHih9+6AanvcsEBj7eMCwEU0CpMAs0H7+gBDwGZjwJNu28fAWzN03+dH6T+8A==
Date: Tue, 17 Feb 2015 17:22:19 +0200
Message-ID: <d7814019afe71ad0c667a01e85620eca@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: francois@php.net, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] Reviving scalar type hints
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Andrey Andreev [mailto:narf@devilix.net]
> Sent: Tuesday, February 17, 2015 4:49 PM
> To: Zeev Suraski
> Cc: francois@php.net; Sara Golemon; PHP internals
> Subject: Re: [PHP-DEV] Reviving scalar type hints
>
> Hi,
>
> On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski <zeev@zend.com> wrote:
> > 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.

I'm not sure we need a silver bullet.  If the conversion and acceptance
rules are clear and reasonable, it's an entirely valid outcome that in cases
where both int and bool are equally acceptable, you won't use a type hint
but rather explicitly cast to int inside the function.

> 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.

Every option has pros and cons.  Since it's clear beyond a reasonable doubt
that we can't all agree on purely weak type hints and equally on purely
strict type hints, it becomes a question of what is the right compromise.
Adding both - which at least from my point of view has major drawbacks (too
prominent zval.type exposure;  complexity of two systems;  internal
functions issue).  Creating something in between that would handle most if
not all of the use cases the strict camp brought up, while not (IMHO) overly
focusing on zval.type and making things a lot more noisy/complex for
built-in functions - is a better direction, whose advantage - I think -
outweigh its disadvantages.

> > 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.

First, let us hope that the situation will be much better to a level that we
don't need to go in that direction :)
But that said, I don't quite see it in the same way.  Internal functions
already commonly use a lot more advanced type checking than is commonly
found in userland functions.  Functions that behave differently depending on
the type of argument you pass, on the number of arguments, etc.  While
technically it's possible to achieve in userland, it's a lot less common.
So while I do see an issue here, I don't think it's *that* bad if it has to
come to that.  Unless we find out our rules work nicely out of the box for
internal functions (which I'm still somewhat hopeful for) - there's no way
to reconcile the fact that internal functions come with this long history of
having detailed type data, while userland functions do not...

Zeev