Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82863
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.3 as permitted sender)
Reply-To: <francois@php.net>
To: "'Arvids Godjuks'" <arvids.godjuks@gmail.com>,
	"'Jefferson Gonzalez'" <jgmdev@gmail.com>
Cc: "'Rowan Collins'" <rowan.collins@gmail.com>,
	"'PHP internals'" <internals@lists.php.net>
Date: Mon, 16 Feb 2015 17:42:12 +0100
Message-ID: <011801d04a07$83ab1c00$8b015400$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AdBKBwSYBIO40ECSRlWtzmDJWY2Lng==
Content-Language: fr
Subject: Reviving scalar type hints
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

Hi,
>
> De : Arvids Godjuks [mailto:arvids.godjuks@gmail.com]
>=20
> 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 =
the
> weak type hints into the language first, see how it gets used and then =
we
> can always add strict type hints if there is a need/desire to do that.
>=20
> 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 =
'return 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 proposed mechanism, there's no possible hinting on such =
argument, which will make the implementation different from the =
documentation. Even if the check is done by the function body, it won't =
be done in a consistent way with type hinting checks and won't raise a =
similar error. As most cases are related 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/return 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 explains how restricting weak conversion possibilities would =
make strict typing almost 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 impossible. To remain consistent between =
userspace/internal functions, this must also be done at the ZPP level.

- Using bare class names as type hints is a potential issue too, as it =
makes 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 'object(class-name)'. If we don't do that, every future addition of a =
type hint keyword will cause a BC break (and will be practically =
impossible).

- Additional 'hybrid' types like 'numeric' and 'mixed' should be also =
provided.

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 =
functions. As Andrea herself agreed, her mechanism for type hinting on =
internal functions 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 argument described as 'string|array' in the =
documentation, wouldn't produce the same 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.