Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83589
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.172 cause and error)
MIME-Version: 1.0
In-Reply-To: <9aec85c81b49009c6238ff6d8be27cd4@mail.gmail.com>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>
	<CAEPJduk3VgWYgpuJ4G0JvUXYaMoO7430Q0k7v5ifwWF_dzh9rA@mail.gmail.com>
	<9aec85c81b49009c6238ff6d8be27cd4@mail.gmail.com>
Date: Mon, 23 Feb 2015 17:53:59 +0100
Message-ID: <CAEPJdukoBG3M1q3UqJ9LW-GBqhVB7-ybkdJqiGENN2w10XqEhw@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c26958a970e3050fc43f84
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: kontakt@beberlei.de (Benjamin Eberlei)

--001a11c26958a970e3050fc43f84
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Zeev,

On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski <zeev@zend.com> wrote:

> Benjamin,
>
>
>
> There=E2=80=99s a fundamental difference between the two RFCs that goes b=
eyond
> 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 u=
s forever;  and in
> the Coercive STH RFC =E2=80=93 the endgame is a single mode with no INI e=
ntries,
> and opening the door to changing the rest of PHP to be consistent with th=
e
> 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.
>

Yes i confirmed this difference. So lets say i am totally against INI and
hopefully many others are as well, then we introduce massive BC breaks in
PHP 7. We got ourselves a Python2/3, Ruby1.8/2 situation here that nobody
wants. I don't like the casting rules that PHP has now, but subtly breaking
them *everywhere* (instead of with declare, by choice) is something I can't
support.

I can forsee Wordpress will not work with kind of BC anymore, so your
(Zends) foremorst goal for PHP7 to get everyone to upgrade because the code
is as fast as HHVM suddenly vanishes in thin air.


>
> 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 beha=
vior is something
> nobody here wants, myself included =E2=80=93 but given that it=E2=80=99ll=
 be time limited
> (perhaps for as short as 1 or 2 years) =E2=80=93 perhaps that=E2=80=99s s=
omething we can
> live with.
>

1-2 years in php-src has absolutely no relation to how long this will be in
userland, probably 2-5 times as long (2-10 years). You are against dual
mode because people need to learn two different styles, however with some
change like this lurking in old hosters and whatnot, how don't we have to
learn about this as well? Its exactly the same thing.


>
>
> 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 ne=
cessary
> when we change E_DEPRECATED to E_RECOVERABLE_ERROR in 7.1/7.2/8.0.
>

4. Agree with you here, not an option.

5. BC Break too big leading to a Python2/3 situation, low adoption of PHP7,
something that especially you couldn't want given that the perf
improvements are what keeps PHP on level with HHVM. This automatically
applies to all internal functions regardless if userland uses typehints or
not, wordpress will not work with this anymore, no performance comparisons
anymore.

6. Ok, so this is now getting very similar like v5 of the STH, but still
with much more BC breaks.


>
>
> 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 quit=
e
> 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
>
>
>

--001a11c26958a970e3050fc43f84--