Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83441
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.180 as permitted sender)
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com> <CAEPJduk3VgWYgpuJ4G0JvUXYaMoO7430Q0k7v5ifwWF_dzh9rA@mail.gmail.com>
In-Reply-To: <CAEPJduk3VgWYgpuJ4G0JvUXYaMoO7430Q0k7v5ifwWF_dzh9rA@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQKcPg+jpyYspJS11b5G1A7RBHpKTgIs5D7Xm1JjpFA=
Date: Sun, 22 Feb 2015 00:25:55 +0200
Message-ID: <9aec85c81b49009c6238ff6d8be27cd4@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b874b2c1f39ae050fa0a76c
Subject: RE: [PHP-DEV] Coercive Scalar Type Hints RFC
From: zeev@zend.com (Zeev Suraski)

--047d7b874b2c1f39ae050fa0a76c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Benjamin,



There=E2=80=99s a fundamental difference between the two RFCs that goes bey=
ond
whether using a global INI setting and the other per-file setting.  The
fundamental difference is that the endgame of the Dual Mode RFC is having
two modes =E2=80=93 and whatever syntax we=E2=80=99ll add, will be with us =
forever;  and in
the Coercive STH RFC =E2=80=93 the endgame is a single mode with no INI ent=
ries,
and opening the door to changing the rest of PHP to be consistent with the
same rule-set as well (implicit casts).   The challenge with the Coercive
STH RFC is figuring out the best transition strategy, but the endgame is
superior IMHO.



Regarding the proposed migration options, yes, if we pick option #2 or #3 =
=E2=80=93
we=E2=80=99d be introducing an INI entry governing runtime behavior is some=
thing
nobody here wants, myself included =E2=80=93 but given that it=E2=80=99ll b=
e time limited
(perhaps for as short as 1 or 2 years) =E2=80=93 perhaps that=E2=80=99s som=
ething we can
live with.



Additional options we could entertain are:

4. Not applying the rules for internal functions at all.  Personally I=E2=
=80=99m
not very fond of this option.

5. Go for just E_DEPRECATED in 7.0.  Change E_DEPRECATED to
E_RECOVERABLE_ERROR in 7.1/7.2/8.0 (TBD).

6. Same as #5, but also provide a mechanism similar to declare() as the
temporary measure for strict campers to explicitly ask for
E_RECOVERABLE_ERROR=E2=80=99s to be triggered.  They will no longer be nece=
ssary
when we change E_DEPRECATED to E_RECOVERABLE_ERROR in 7.1/7.2/8.0.



Thoughts?



Zeev



I was really looking forward to the RFC. However the dependence on an INI
setting and the question of massive internal BC break are a bit too much I
think.



They are necessary as you explain to allow internal functions/ZPP to have
the same conversion rules as userland functions. This INI setting is quite
similar to introducing two modes as well, but on the server configuration
level instead in a much more fine granular way in scalar type hints v0.5.



I see much more compatibility problems for third party libraries here.



Now if I had to decide between having two modes on a granular file level or
an INI setting (option 2/3) or massive BC breaks (option 1) to get scalar
type hints in PHP, then two modes with declare() doens't look, because I
can pick the mode I want, and no-one can force it on me.





Zeev

--047d7b874b2c1f39ae050fa0a76c--