> -----Original Message-----
> From: Ole Markus With [mailto:olemar...@olemarkus.org]
> Sent: Thursday, March 12, 2015 10:10 AM
> To: Pierre Joye; Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
>
>
>
> On 03/11/2015 09:05 PM, Pierre Joye wrote:
> > On Mar 12, 2015 2:10 AM, "Zeev Suraski" <z...@zend.com> wrote:
> >>
> >> The vote on the Coercive Scalar Type Hints is now open for voting.
> >>
> >>
> >>
> >> The latest version of the RFC includes changes discussed on
> >> internals@
> > last
> >> week:
> >>
> >> 1. Accept string->bool and int->bool conversions (false->bool is not
> >> supported)
> >>
> >> 2. Accept leading/trailing spaces in string->number conversions.
> >>
> >>
> >>
> >> wiki.php.net/rfc/coercive_sth
> >>
> >> wiki.php.net/rfc/coercive_sth#vote
> >
> > Voted no for the following reasons:
> >
> > - change default casting, which has been working since years,
> > consistently inconsistent
> > - due to the previous nature of changes, we have no way to be sure we
> > won't break anything badly out there
> > - big changes in the RFC+patch between last discussions and vote.
> > Should not be allowed, can't veto it so voted no
> >
>
> I changed my vote to no for the same reasons.
I'm sorry to hear that Ole Markus. I do want to address these concerns:
> - change default casting, which has been working since years,
> consistently inconsistent
> - due to the previous nature of changes, we have no way to be sure we
> won't break anything badly out there
Casting rules aren't touched - it's rules for internal function arguments
that are changed. This has been a key premise of this proposal since the
beginning; Contrary to the 2nd statement, we have a pretty good way of
knowing it won't break things badly out there - running it with real world
apps and our test suite. As the Impact On Real World Applications section
suggests (wiki.php.net/rfc/coercive_sth#changes_to_internal_functions) -
the real world impact is minimal, since the conversion which are blocked are
rarely relied upon in apps. The issues you do get are almost always
legitimate issues - with excellent signal to noise ratio. Users would have
several YEARS to fix these issues before they become errors and not
warnings. Many of the compatibility breakages we've done over the years
(and in 7) had / would have a lot farther reaching impact - often with zero
end-user gain to show for it.
What is being consistently ignored by everyone is the fact that large
projects - with the absence of having a good dynamic option - are likely to
implement strict project-wide, resulting in WAAAY bigger breakage, since the
strict mode does not differentiate between sensible conversions, that have
been relied upon in PHP for the last 20 years ("32" -> 32) and nonsensible
conversions that are for the most part a side effect of implementation ("100
dogs" -> 100).
> - big changes in the RFC+patch between last discussions and vote.
> Should not be allowed, can't veto it so voted no
There have been NO big changes to the proposal - only two tweaks which I
clearly detailed in the Vote email, that have been publicly discussed in
detail on internals@ more than a week ago. There is absolutely no rule in
the voting RFC that requires a long period of time between the last changes
to the RFC and the vote. The mandatory discussion period starts ticking
when the RFC is sent to the list, not when the last changes are made to it.
Anyone claiming otherwise is misleading, as both the text in
wiki.php.net/rfc/voting#discussion_period is clear about when the ticking
starts - and on top of that, I can tell you as the person who introduced the
mandatory discussion period and wrote that text, that resetting the clock on
every change to the RFC was never ever even remotely considered or intended
as a requirement.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
