Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82891
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <011801d04a07$83ab1c00$8b015400$@php.net>
References: <011801d04a07$83ab1c00$8b015400$@php.net>
Date: Mon, 16 Feb 2015 17:00:14 -0500
Message-ID: <CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>
To: francois@php.net
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>, Jefferson Gonzalez <jgmdev@gmail.com>, 
	Rowan Collins <rowan.collins@gmail.com>, 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: pjsturgeon@gmail.com (Philip Sturgeon)

On Mon, Feb 16, 2015 at 11:42 AM, Fran=C3=A7ois Laupretre <francois@php.net=
> wrote:
> Hi,
>>
>> De : Arvids Godjuks [mailto:arvids.godjuks@gmail.com]
>>
>> The 0.1 RFC version was mentioned a lot as a good compromise by many
>> people
>> and had major support.
>> Maybe someone competent could pick it up, make necessary adjustments
>> that
>> where required and let people vote on it? Start with small steps - get t=
he
>> weak type hints into the language first, see how it gets used and then w=
e
>> can always add strict type hints if there is a need/desire to do that.
>>
>> That way we finally get type hints into the language, and those wanting =
the
>> strict variety have all the opportunities in the world to add them at a
>> later release with proper discussion and development time.
>
> That's what I am planning. If I write an RFC, it will be based on Andrea'=
s 0.1/0.2 version, and won't propose different modes.
>
> The problem is that the previous controversial RFC focused people on weak=
 vs strict typing, while we should have explored other technical concerns. =
Here are the main ones I see :
>
> - the fact that the RFC supports single types only, like the previous 're=
turn type' RFC. While it is easier to implement, it opens several issues as=
 multiply-typed arguments are an integral part of the PHP language (mostly =
completeness and compatibility with internal function hinting). If we want =
to support multiple types the same way for internal and userspace functions=
, we must extend the ZPP layer to support it.
>
> - the mechanism to check for type hints on internal functions, while easy=
 to implement, is not sufficient, as a lot of internal functions get a bare=
 zval from the parsing system and then convert it by themselves. With the p=
roposed mechanism, there's no possible hinting on such argument, which will=
 make the implementation different from the documentation. Even if the chec=
k is done by the function body, it won't be done in a consistent way with t=
ype hinting checks and won't raise a similar error. As most cases are relat=
ed to multiply-typed args, the solution is in adding multiply-typed support=
 to ZPP. Multiply-typed support needs to redefine scalar conversion rules, =
to take care of the target type being a combination of single types.
>
> - We need to define the appropriate extension to Reflection parameters/re=
turn type. That's not complex, but it takes time.
>
> - Other changes I'd like to propose are exposed in Bob Weinand's article,=
 at https://gist.github.com/bwoebi/b4c5564388ecd004ba96. The article explai=
ns how restricting weak conversion possibilities would make strict typing a=
lmost useless. Changes include forbidding bool to int/float or '7years' to =
int. This cannot be left for future additions as BC breaks will make it imp=
ossible. To remain consistent between userspace/internal functions, this mu=
st also be done at the ZPP level.
>
> - Using bare class names as type hints is a potential issue too, as it ma=
kes reserved keywords and class names share the same naming space. I think =
we should deprecate the use of class names as type hints in favor of 'objec=
t(class-name)'. If we don't do that, every future addition of a type hint k=
eyword will cause a BC break (and will be practically impossible).
>
> - Additional 'hybrid' types like 'numeric' and 'mixed' should be also pro=
vided.
>
> So, most features I have in mind are really 'now or never'.
>
> My main concern, anyway, is with March 15 announced feature freeze. If we=
 need a vote by this date, it's impossible. And planning such BC for 7.1 is=
 probably unrealistic because of the huge syntax additions and BC breaks it=
 brings. So, if it's too late for an inclusion in 7.0, I think I'll give up=
.
>
> So, could someone confirm what 'feature freeze' exactly means ?
>
> Regards
>
> Fran=C3=A7ois
>
>
>
>
>
>
>
>
>  The main issues are completeness (we can give hints for some cases, but =
not for others) and, more important, the compatibility with internal functi=
ons. As Andrea herself agreed, her mechanism for type hinting on internal f=
unctions is not sufficient. Just using the ZPP macros, as they exist today,=
 won't work as a lot of internal functions get a bare zval and then convert=
 it by themselves. So, in this case, we would check nothing. So, an argumen=
t described as 'string|array' in the documentation, wouldn't produce the sa=
me sort of error when sent an object, than its friend, described as 'string=
'. This is not consistent and will open a lot of side effects if it is left=
 out of the type hint layer.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

I know it is very easy for people to say "Well, that v0.3 that I
didn't like has been withdrawn, so let's just crack on and do some
other new thing." but I would have to ask people to consider that v0.3
had two thirds majority, with a few people clearly admitting that
their No vote was down to declare.

So, if declare is the only thing blocking v0.3 from passing, despite
1/3rd of voters being sad about it, let's just go down that road
instead of throwing the baby out with the bath water and coming up
with some new approach that will be bike-shedded over until PHP 8 is
in feature freeze.