Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84062
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
Message-ID: <54F116F3.1060101@garfieldtech.com>
Date: Fri, 27 Feb 2015 19:16:35 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAAyV7nGf7BGLAK5e2AhJ25VLQmCfoNZjUU0HDDN4Zrxq8aVyHQ@mail.gmail.com>
In-Reply-To: <CAAyV7nGf7BGLAK5e2AhJ25VLQmCfoNZjUU0HDDN4Zrxq8aVyHQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][VOTE] Scalar Type Declarations v0.5
From: larry@garfieldtech.com (Larry Garfield)

On 2/26/15 8:58 AM, Anthony Ferrara wrote:
> All,
>
> I have opened voting on Scalar Type Declarations v0.5. Please cast your vote.
>
> https://wiki.php.net/rfc/scalar_type_hints_v5#vote
>
> The vote will remain open until March 13th, 2015 or until the date a
> competing RFC closes voting, whichever is later.
>
> Thanks
>
> Anthony

As both you and Matthew noted in an earlier thread, technically these 
RFCs are not competing.  They're not Apples and Oranges, but more like 
Gala Apples and Honeycrisp apples.  (Now I'm hungry...)

We seem to all be agreed about adding scalar type hints, starting from 
the current "weak" baseline.  Yay, agreement!  Can haz?  Please?  After 
all these years?

One proposal is to then go a step further and add a pedantic (strict) 
mode that is opt-in by the caller.  Pros and Cons.

Another proposal is to tighten up the casting rules of PHP itself, with 
the exact tightening to do still being up for debate.  Pros and Cons.

Those are not mutually exclusive.  They're not quite orthogonal, but 
they're distinct asks.  Personally I rather like both.  I think the 
doom-and-gloom charges against both are greatly over-wrought.  And 
remember that in both cases, *all scalar typing is still opt-in* for 
user-space code.

I would argue absolutely against another ini setting that changes the 
language behavior.  (As in, Holy mother of Vint Cerf <censored> that 
<censored>!)  But the more recent samples from Zeev seem promising that 
the changes are minor enough that we won't need that.

The main questions seem to me:

1) For strict mode, is it going to lead to sufficient confusion that 
people abuse it and do stupid things, and is that risk larger than the 
potential benefit of easier static analysis (either offline or at 
compile time) in the future?  I am fairly well convinced that if used 
judiciously a reasonable codebase can leverage strict mode quite heavily 
without having to throw lots of casts around.  What percentage of the 
PHP using population can be "judicious" is a debatable point.

2) For pickier coercion, is the tightening of types on core functions 
(remember, opt-in for user-space code) going to cause sufficient 
breakage that people are dissuaded from upgrading?  This depends heavily 
on what gets tightened, so we can debate that at length, but I believe 
it is possible to tighten them enough to be useful without being so 
tight that it breaks the whole world.

Also, keep in mind there's 2 classes of software to think about.  The 
Drupal, Wordpress, Magento, Symfony, etc. developers will update their 
code to be compatible no matter what.  Those core systems will get 
enough pushback that they'll update one way or another; the developers 
may throw rotten apples at us (either gala or honeycrisp), but we 
survived call time pass by reference and the tighter array/string 
conversion handling in 5.4.  Speaking as a Drupal developer: We'll 
manage.  (And those big systems account for, all together, a majority of 
the lines of PHP actually running in the wild today; to be fair that's 
mostly Wordpress's doing but still.)

Then there's the random script kiddy code, or the code that was 
perfectly sensible in 2002 that is still running unchanged despite 
everyone's best judgement.  This is the code that scares shared hosts. 
That code probably won't be moved to a PHP 7 server until 7.4 is out 
*anyway*, no matter what we do.  How badly tighter coercion rules 
impacts this code is a debatable point, and heavily dependent on what 
tightening happens.

In any case, my point is that we don't need to make it an either/or 
question.  These are both viable, logical extensions to adding basic 
scalar typing, but not mutually exclusive and no need to turn into 
"camps".  If both pass, that's OK.  Really, it's OK.  Go home and have 
an apple. :-)

--Larry Garfield