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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
