Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83800
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <b72cac641e4bfddc212c01ae46a40ac5@mail.gmail.com>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>
	<CAAyV7nHq_-9jyRcwJmiAxthmEo3u3MDXcyOC09LV2DETABzCoA@mail.gmail.com>
	<8250289916f5128b5bc1a114428d374e@mail.gmail.com>
	<CAAyV7nHAicJCQU87YkhZ700a=k4MRqVJtMV-mG4F0MQsn82OfQ@mail.gmail.com>
	<e7bfa71fe190a2577b329092b46da5dd@mail.gmail.com>
	<CAAyV7nGrh30VdYbU6j3oHwQHX_S81LdQ8iZAe4zZcAT1xOZ-uA@mail.gmail.com>
	<b72cac641e4bfddc212c01ae46a40ac5@mail.gmail.com>
Date: Wed, 25 Feb 2015 07:31:25 -0800
Message-ID: <CAEZPtU7dj3ezgbf1eNGxtbnOuc65R=Ljfe4-V6R1Wj4egcC8eQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: pierre.php@gmail.com (Pierre Joye)

On Sat, Feb 21, 2015 at 2:47 PM, Zeev Suraski <zeev@zend.com> wrote:

>> "with two potential 'camps' of developers forming up"
>>
>> Have you looked at the community lately? That's been happening for a
>> decade. One camp likes to engineering everything out using classes and
>> libraries. The other keeps using PHP procedurally and ignoring changing
>> "best
>> practices" (and I do mean the quotes). Does that make one better than th=
e
>> other? NO.
>
> I don't think these two camps map to the strict and dynamic camps,
> definitely not for the userbase at large.

Actually yes, it is slightly like that.

> Which means that whatever camps we have today, we'd have more - one extra
> point of division.

We do, while one RFC allows a smooth, BC breaks free (100% safe)
migration path to 7 for existing apps or code.

>> And that's PHP's strength. It gives both sides the power to keep doing
>> what
>> they want to be doing without having to give up or be burdened by the
>> other
>> side.
>
> I explained both in the RFC and here why I don't think providing two mode=
s
> for doing something quite similar are good.  We can agree to disagree :)

And I explain here many times why changing the casting rules is a bad
risky idea to begin with.

>> Sure, some people will do that. Just like people still use single quotes
>> because
>> they are faster.
>
> Not quite IMHO - that example actually requires some relatively advanced
> knowledge.  Strict, with the amount of noise that Scalar Type Hints are
> bound to get (and are already getting) - is bound to have a lot more
> exposure than single quotes being faster ever had.  And it's therefore ve=
ry
> likely it'll be used by people who shouldn't really be using it.
>
> Let's leave the Static Analysis part aside, and agree to disagree as we
> already did numerous times but failed to implement.

Pure suppositions and again extrapolating from nothing. It is as
always a documentation matter and as usual many users won't even know
it exists and simply update PHP. It should work smoothly, without BC
and that's what will happen by default if we don't change the default
way to deal with casts.

>> > Two more things regarding the competing RFC =E2=80=93 it=E2=80=99s sti=
ll alive, and
>> > being promoted for PHP 7.0;  And while it doesn=E2=80=99t create a hug=
e BC
>> > break, it allows developers to selectively create localized BC breaks,
>> > on a per file basis.
>>
>> No, it does not. A BC break is something where existing code works, and
>> you
>> do nothing more than upgrade and have the new code not work anymore.
>>
>> With the other dual-mode RFC, if a user opts-in (enables strict mode), i=
f
>> code
>> doesn't work that's not a BC break. That's a case of "you told us explic=
it
>> you
>> don't want this code to work if it's invalid, and guess what, it's
>> invalid".
>
> That's splitting hairs IMHO.  The bottom line is that many people will
> undergo the same process Rasmus did as he experimented, flipping the swit=
ch
> on because it's a best practice, and start having to fix their code to wo=
rk.
> But we can also agree on what we always agree here too :)

It is not splitting hair, it is the key point of the dual mode. A
given user can simply ignore the type hinting and keep using what its
apps do, and it will work. He can as well focus one area, or addon to
its app, to use strict mode (and will only apply to the files used by
this specific addon and nowhere else!! ).

With the other RFC, which changes the casting modes, I wish everyone
good luck. I may be wrong, can happen ;), but we simply do not know
and will not know before 7.0.0 is out. Good luck to change them again
to "adapt and tweak", and good luck to the apps developers to adapt
their apps with plenty of patch versions checks. This is the reason #2
why I am against your RFC, the #1  being the total lack of actual non
magic casting (read: strict), optionally enabled.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org