Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82968
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.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Zeev Suraski'" <zeev@zend.com>,
	"'Sara Golemon'" <pollita@php.net>
Cc: "'PHP internals'" <internals@lists.php.net>
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>
In-Reply-To: <1913e09d7f52541901d8574d2080a63f@mail.gmail.com>
Date: Tue, 17 Feb 2015 16:03:21 +0100
Message-ID: <024c01d04ac2$dee5d720$9cb18560$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGD0sLDaA+/0NIeBlQhQC5OtPA/xwHih9+6AanvcsEBj7eMCwEU0CpMAs0H7+gBDwGZjwJNu28fnSr6eBA=
Content-Language: fr
Subject: RE: [PHP-DEV] Reviving scalar type hints
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : Zeev Suraski [mailto:zeev@zend.com]
>
> Even though that's not what I meant when I sent my proposal in the
> morning,

Sorry, I was not clear enough : it was my position only.

> 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.

ZPP already chose a while ago to implement a much restricted conversion =
set from convert_to_xxx() rules. The objective is not the same, as =
casting must be as permissive as possible (we could discuss that in the =
future too...). I hope we all agree to keep scalar type hinting aligned =
on ZPP rules.

I also think we all agree, while implicitely, on the ruleset changes =
we're expecting. I am currently writing this down, so that we have a =
written base to discuss.

Just one detail, to be sure we are in sync : new conversion rules will =
remain in sync between zend_parse_parameters() and zpp, while future =
additional types will be defined in zpp only. I assume we are OK to =
refuse extending the zend_parse_parameters() format in the future.

> 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.  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.

I fully agree with you and Rasmus. Strict typing, as defined in 0.3, =
does not fit with internal functions.

To summarize, we have two options :

- differentiate behavior and run weak checks on internal functions, even =
if strict switch is on.
- attempt to get back to a single-mode mechanism, which would keep both =
worlds in sync.

I definitely prefer to explore the second one.

> 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,

Why not, but let's first try avoiding it first, as we'll bikeshed during =
weeks on the syntax for new keywords.

Remember that class names share the same naming space as type hint =
keywords. So, defining new keywords will lead to endless discussions. =
And stating, as I heard, that we just have to use lowercase-only =
keywords, is not serious. That's a little off-topic here, but I would =
also propose to deprecate using bare class names as type hints from 7.0. =
That's a big BC change and a lot will hate that, but the issue was =
created when the 'array' type hint was added, and we need to fix it =
(proposing an alternate syntax like 'object(classname)'). As long as we =
support bare class names, adding a new type is almost impossible and =
typedef is *totally* impossible. It's just deprecating, but the impact =
is such that it can come with a major version only. A smoother path can =
be to introduce the alternate syntax in 7.0, then deprecate in 7.1 or =
7.2. It will take more time but it's probably better.

> > 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.
>=20
> I think we all agree about that.

Fine :) !

Regards

Fran=C3=A7ois