Hi all,
I have just opened the vote on this RFC.
The main goal of the RFC is to eliminate the inconsistency in arrays when
negative numeric keys are used explicitly and the following implicit keys
will start from zero.
You can find the RFC here: https://wiki.php.net/rfc/negative_array_index
The previous discussion: https://externals.io/thread/712
And the PR (also some discussion): https://github.com/php/php-src/pull/2383
Voting is open from now until 20/6/2017 18:00 UTC.
Regards,
Pedro
Hi all,
I have just opened the vote on this RFC.
The main goal of the RFC is to eliminate the inconsistency in arrays when
negative numeric keys are used explicitly and the following implicit keys
will start from zero.You can find the RFC here: https://wiki.php.net/rfc/negative_array_index
The previous discussion: https://externals.io/thread/712
And the PR (also some discussion): https://github.com/php/php-src/pull/2383
I voted no because of the BC break.
cheers,
Derick
Hi,
The same for me. Strange to see 7 people willing to introduce such a BC
break in a minor version, or did I miss something ?
Anyway, +1 to introduce the change in PHP 8.
Cheers,
François
Le 07/06/2017 à 13:31, Derick Rethans a écrit :
Hi all,
I have just opened the vote on this RFC.
The main goal of the RFC is to eliminate the inconsistency in arrays when
negative numeric keys are used explicitly and the following implicit keys
will start from zero.You can find the RFC here: https://wiki.php.net/rfc/negative_array_index
The previous discussion: https://externals.io/thread/712
And the PR (also some discussion): https://github.com/php/php-src/pull/2383
I voted no because of the BC break.cheers,
Derick
Voting "no" as well, since applications relying on "array_keys()" and
assuming on the allowed integer range of those may even become vulnerable.
This is one of those subtle BC breaks that are extremely hard to find.
Hi,
The same for me. Strange to see 7 people willing to introduce such a BC
break in a minor version, or did I miss something ?Anyway, +1 to introduce the change in PHP 8.
Cheers,
FrançoisLe 07/06/2017 à 13:31, Derick Rethans a écrit :
Hi all,
I have just opened the vote on this RFC.
The main goal of the RFC is to eliminate the inconsistency in arrays when
negative numeric keys are used explicitly and the following implicit keys
will start from zero.You can find the RFC here: https://wiki.php.net/rfc/negative_array_index
The previous discussion: https://externals.io/thread/712
And the PR (also some discussion): https://github.com/php/php-src
/pull/2383I voted no because of the BC break.
cheers,
Derick
Am 07.06.2017 um 13:31 schrieb Derick Rethans:
I voted no because of the BC break.
Same.
I voted no because of the BC break.
Changed my vote to no for the same reason. The subtly of the BC would make bugs potentially difficult to discern. Would happily vote yes again for an RFC targeting 8.
Aaron Piotrowski
Hi all,
I have just opened the vote on this RFC.
The main goal of the RFC is to eliminate the inconsistency in arrays when
negative numeric keys are used explicitly and the following implicit keys
will start from zero.You can find the RFC here: https://wiki.php.net/rfc/negative_array_index
The previous discussion: https://externals.io/thread/712
And the PR (also some discussion): https://github.com/php/php-src/pull/2383Voting is open from now until 20/6/2017 18:00 UTC.
I don't think that the current behavior makes much sense, but since it
is well documented and it isn't a bug, changing it in a minor version
wouldn't comply to our release process[1]. Therefore, I've voted
against, but I'd be happy to see this improvement in PHP 8.
[1] https://wiki.php.net/rfc/releaseprocess#releases_cycle
--
Christoph M. Becker
Hi,
Right. Introducing this change is not compatible with the release
process, whatever the result of the vote.
So, I respectfully ask you to change target to PHP 8 or explain why we
should make an exception to the process. Reasons you gave so far are OK
for a major version, but not for a minor one. This is not against you or
your work, as I'd also like to change such inconsistent behavior, but
the probability of BC break is too high, IMO.
Regards
François
Le 07/06/2017 à 14:19, Christoph M. Becker a écrit :
Hi all,
I have just opened the vote on this RFC.
The main goal of the RFC is to eliminate the inconsistency in arrays when
negative numeric keys are used explicitly and the following implicit keys
will start from zero.You can find the RFC here: https://wiki.php.net/rfc/negative_array_index
The previous discussion: https://externals.io/thread/712
And the PR (also some discussion): https://github.com/php/php-src/pull/2383Voting is open from now until 20/6/2017 18:00 UTC.
I don't think that the current behavior makes much sense, but since it
is well documented and it isn't a bug, changing it in a minor version
wouldn't comply to our release process[1]. Therefore, I've voted
against, but I'd be happy to see this improvement in PHP 8.
Hi,
Right. Introducing this change is not compatible with the release process,
whatever the result of the vote... explain why we
should make an exception to the process.
The RFC process is the way that we change the rules, and RFCs are not
constrained by any previous RFC or by any 'constitution' as PHP
doesn't have one. This is similar to how the UK parliament isn't
constrained by any previous decision or constitution, which is
different from most other countries, where the power of the government
is limited by constitution.
It behooves people to pay attention to RFCs announced on this list,
and to raise their concerns during the comment phase - not to ask for
"why is this is being allowed" only when the voting starts. To be
clear, I'm referring to some of the more dramatic twitter
communications rather than any emails to this list.
Also, I'd be more comfortable with this targeting PHP 8 - though I'm
hoping someone would demonstrate some actual code that will break,
which would make it easier to decide, rather than just people claiming
stuff might break.
cheers
Dan
The RFC process is the way that we change the rules, and RFCs are not
constrained by any previous RFC or by any 'constitution' as PHP
doesn't have one. This is similar to how the UK parliament isn't
constrained by any previous decision or constitution, which is
different from most other countries, where the power of the government
is limited by constitution.
Even without a written constitution, you can't simply pass something that incidentally changes a pre-established rule, you have to explicitly make an exception or a new rule.
To take the analogy of English Law, if two Acts conflicted without mentioning each other, I don't think it would be a foregone conclusion that the newer law should be followed. What's more, there are laws that explicitly constrain the process of passing other laws - the Parliament Acts, for instance, or the Human Rights Act.
If you can simply say "this conflicts with our agreed procedures, but it's newer, so the procedures are automatically wrong" then you might as well not have any procedures. Saying "this is an acceptable exception to normal procedures because..." seems a reasonable minimum requirement.
Regards,
--
Rowan Collins
[IMSoP]
On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins rowan.collins@gmail.com
wrote:
you can't simply pass something that incidentally changes a
pre-established rule
Hi Rowan,
Would you consider that that is not the case for your own RFC?
https://wiki.php.net/rfc/deprecate-bareword-strings
On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins rowan.collins@gmail.com
wrote:you can't simply pass something that incidentally changes a
pre-established ruleHi Rowan,
Would you consider that that is not the case for your own RFC?
https://wiki.php.net/rfc/deprecate-bareword-strings
I'm sorry, I don't follow. What rule is broken, incidentally or explicitly, by that RFC?
--
Rowan Collins
[IMSoP]
On Wed, Jun 7, 2017 at 5:38 PM, Rowan Collins rowan.collins@gmail.com
wrote:
On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins rowan.collins@gmail.com
wrote:you can't simply pass something that incidentally changes a
pre-established ruleHi Rowan,
Would you consider that that is not the case for your own RFC?
https://wiki.php.net/rfc/deprecate-bareword-stringsI'm sorry, I don't follow. What rule is broken, incidentally or
explicitly, by that RFC?--
Rowan Collins
[IMSoP]--
The page that was already mentioned on this thread:
https://wiki.php.net/rfc/releaseprocess#releases_cycle explicitly states
the following:
x.y.z to x.y+1.z
Backward compatibility must be kept
However, a number of already implemented RFCs for 7.2 do not follow that
rule strictly:
- https://wiki.php.net/rfc/number_format_negative_zero
- https://wiki.php.net/rfc/convert_numeric_keys_in_object_array_casts
- https://wiki.php.net/rfc/deprecate-bareword-strings
- https://wiki.php.net/rfc/get_class_disallow_null_parameter
- https://wiki.php.net/rfc/counting_non_countables
- https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp
- https://wiki.php.net/rfc/hash-context.as-resource
- https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003
- As well as some of the RFCs still pending implementation
I don't mean at all that these should not have been accepted. Especially
the ones that initiate a deprecation phase. But it is seems to me that this
RFC does not break any rule that has been upheld strictly up to this point.
Regards,
Pedro
On Wed, Jun 7, 2017 at 5:38 PM, Rowan Collins rowan.collins@gmail.com
wrote:On 7 June 2017 15:23:13 BST, "Pedro Magalhães" mail@pmmaga.net
wrote:On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins
rowan.collins@gmail.com
wrote:you can't simply pass something that incidentally changes a
pre-established ruleHi Rowan,
Would you consider that that is not the case for your own RFC?
https://wiki.php.net/rfc/deprecate-bareword-stringsI'm sorry, I don't follow. What rule is broken, incidentally or
explicitly, by that RFC?The page that was already mentioned on this thread:
https://wiki.php.net/rfc/releaseprocess#releases_cycle explicitly
states
the following:x.y.z to x.y+1.z
Backward compatibility must be kept
However, a number of already implemented RFCs for 7.2 do not follow
that
rule strictly:
...
I don't mean at all that these should not have been accepted.
Especially
the ones that initiate a deprecation phase.
Deprecating something is basically the opposite of breaking backwards compatibility in a minor release. The entire point of deprecation messages is to indicate ahead of time that something will be broken later, but not break it yet. Unless you're being purposefully pedantic to try and prove that black is white, adding any log message is barely even a functional change, let alone a breaking one.
That said, there are sometimes RFCs that break the rule. Usually, they get feedback regarding the break, just as this one is. Often, they attempt to justify an exception to the rule, as I and others have suggested this one could. I don't always agree with the way those exceptions are applied (too_few_args was one I opposed, for instance).
I hope you can see that saying "well, we allow people to fix spelling mistakes in error messages, so we might as well allow changes that completely change the behaviour of a core function" is pretty ridiculous. We have a rule, there are grey areas, and we try to navigate them; in this case, people are saying the RFC has fallen the wrong side of that grey area. If you disagree, feel free to comment on this specific case.
Regards,
--
Rowan Collins
[IMSoP]
Am 07.06.2017 um 16:23 schrieb Pedro Magalhães:
On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins rowan.collins@gmail.com
wrote:you can't simply pass something that incidentally changes a
pre-established ruleHi Rowan,
Would you consider that that is not the case for your own RFC?
https://wiki.php.net/rfc/deprecate-bareword-strings
have you seen any valid uecase for that in the past 15 years which was
not a typo in a constant name or forgotten quotes?
Right. Introducing this change is not compatible with the release process,
whatever the result of the vote... explain why we
should make an exception to the process.The RFC process is the way that we change the rules, and RFCs are not
constrained by any previous RFC […]
If that was so, we wouldn't even be bound to the "Voting on PHP
features" RFC[1], which wouldn't make sense, IMHO.
[1] https://wiki.php.net/rfc/voting
--
Christoph M. Becker
On Wed, Jun 7, 2017 at 2:41 PM, François Laupretre francois@tekwire.net
wrote:
So, I respectfully ask you to change target to PHP 8 or explain why we
should make an exception to the process. Reasons you gave so far are OK for
a major version, but not for a minor one. This is not against you or your
work, as I'd also like to change such inconsistent behavior, but the
probability of BC break is too high, IMO.
I will not change the target version now during the voting phase. Also
because it wouldn't make sense to vote for a feature for 8.0 yet. If the
RFC is rejected and the sentiment is that most people would agree with the
change but not with the timing, I will propose it again when RFCs for 8.0
are relevant.
Thanks,
Pedro
I will not change the target version now during the voting phase. Also
because it wouldn't make sense to vote for a feature for 8.0 yet. If the
RFC is rejected and the sentiment is that most people would agree with the
change but not with the timing, I will propose it again when RFCs for 8.0
are relevant.Thanks,
Pedro
It does not loose relevance just because the implementation is
postponed. On the contrary, we could directly start advertising that
change, which is super useful to the PHP ecosystem because they can
prepare their code for the change.
The change you are proposing is absolutely necessary, and it is a great
initiative of yours! :)
However, the possibility of introducing this kind of change in a minor
is dangerous. I am usually against almost all of these changes, but in
favor of deprecation to fix more of these unexpected features.
--
Richard "Fleshgrinder" Fussenegger
Hi Pedro,
Le 07/06/2017 à 20:23, Pedro Magalhães a écrit :
I will not change the target version now during the voting phase. Also
because it wouldn't make sense to vote for a feature for 8.0 yet. If the
RFC is rejected and the sentiment is that most people would agree with
the change but not with the timing, I will propose it again when RFCs
for 8.0 are relevant.
I am sorry you take it this way. Voting today on a feature for 8.0
wouldn't be ridiculous and it would make me change my vote, as most
others. Instead of nonsense, it would be a sign of maturity for the PHP
project. It would be great, IMO, to open a 'Approved for 8.0' section on
the RFC page now, and your RFC could proudly be the 1st one to enter it.
This would prove, IMO again, that we are finally able to think more long
term than we did in the past. The most interesting proposals for 7.0
were rejected before it was too late to introduce such disruptive
changes. They should have been prepared a long time before, introducing
a compatibility path, so that people could prepare their code. This was
also one of the reasons for the failure of PHP 6.
So, advertising a future BC break months before a release perfectly
makes sense. The only risk would be to forget it but, by creating a
specific section on the RFC page, we ensure it won't. In theory, it
should even work this way : gather proposals, vote, feature freeze,
implements PRs, merge them, and, only at this time, start publishing
alpha, beta, RC, final. We accept changes after publishing alpha because
most people wake up too late. So, I encourage you again to initiate a
much more mature way of planning the next major version !
Regards
François
It would be great, IMO, to open a 'Approved for 8.0' section
on
the RFC page now, and your RFC could proudly be the 1st one to enter
it.
I definitely agree with this, as I've argued before for a more timeline based approach to major releases to avoid / reduce a repeat of the "quick, while 7.0 is on the table" RFC rush, and the "well, 7.1 is still kinda the beginning of 7.x, so we can break things a little" kludges.
There is still the question of how to ease the transition, though: a subtle break documented years in advance is still a subtle break, so we need to think what form of deprecation is useful to developers. That means more than restarting voting with a new target version, and if the final target is 8.0, there's no rush to hold that new vote.
Regards,
--
Rowan Collins
[IMSoP]
It would be great, IMO, to open a 'Approved for 8.0' section
on
the RFC page now, and your RFC could proudly be the 1st one to enter
it.I definitely agree with this, as I've argued before for a more timeline based approach to major releases to avoid / reduce a repeat of the "quick, while 7.0 is on the table" RFC rush, and the "well, 7.1 is still kinda the beginning of 7.x, so we can break things a little" kludges.
I second that. Consider, for instance, the "Deprecate and remove
INTL_IDNA_VARIANT_2003" RFC[1]. It has been decided to change the
default of idn_to_*() to INTL_IDNA_VARIANT_UTS46 as of PHP 7.4. But
what if there will not even be a PHP 7.4? Also it has been decided to
remove support for INTL_IDNA_VARIANT_2003 as of PHP 8.0. What if there
will be a PHP 7.42 – would we have to wait for decades to remove
INTL_IDNA_VARIANT_2003 support?
[1] https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003
--
Christoph M. Becker
I am sorry you take it this way. Voting today on a feature for 8.0
wouldn't be ridiculous and it would make me change my vote, as most others.
Instead of nonsense, it would be a sign of maturity for the PHP project. It
would be great, IMO, to open a 'Approved for 8.0' section on the RFC page
now, and your RFC could proudly be the 1st one to enter it.
I agree with your suggestion and general sentiment so I propose to do the
following:
- The current voting widget refers to introducing the change on 7.2.
(Will be mentioned on the RFC page) - Add a new voting widget for introducing the change on 8.0.
- Extend the voting period for one more week than originally planned
until 27/6/2017 18:00 UTC.
Additionally, since some people also mentioned the difficulty in detecting
this change, if the vote for 8.0 passes, I suggest to introduce a
E_DEPRECATED notice where the implicit keys will change. You can see that
implementation here:
https://github.com/php/php-src/compare/master...pmmaga:negative-array-deprecated
Would it make sense to include an extra voting widget for the introduction
of the notice?
Given that we are on the voting phase I would oppose changing anything by
principle, but given that most of the discussion on the topic only started
when the vote was started and what is dividing the vote is the timing, I
think it makes sense to update the RFC in this case. Let me know what you
think.
Thanks,
Pedro
Pedro,
It would be best to just kill the vote and start over. The proposal should
be for deprecation notice in 7.2 and implementation in 8.0 IMO — it should
be one vote, as doing both together should be the only option.
- Davey
On Thu, Jun 8, 2017 at 9:52 AM, François Laupretre francois@php.net
wrote:I am sorry you take it this way. Voting today on a feature for 8.0
wouldn't be ridiculous and it would make me change my vote, as most
others.
Instead of nonsense, it would be a sign of maturity for the PHP project.
It
would be great, IMO, to open a 'Approved for 8.0' section on the RFC page
now, and your RFC could proudly be the 1st one to enter it.I agree with your suggestion and general sentiment so I propose to do the
following:
- The current voting widget refers to introducing the change on 7.2.
(Will be mentioned on the RFC page)- Add a new voting widget for introducing the change on 8.0.
- Extend the voting period for one more week than originally planned
until 27/6/2017 18:00 UTC.Additionally, since some people also mentioned the difficulty in detecting
this change, if the vote for 8.0 passes, I suggest to introduce a
E_DEPRECATEDnotice where the implicit keys will change. You can see that
implementation here:
https://github.com/php/php-src/compare/master...pmmaga:
negative-array-deprecated
Would it make sense to include an extra voting widget for the introduction
of the notice?Given that we are on the voting phase I would oppose changing anything by
principle, but given that most of the discussion on the topic only started
when the vote was started and what is dividing the vote is the timing, I
think it makes sense to update the RFC in this case. Let me know what you
think.Thanks,
Pedro
Am 12.06.2017 um 08:14 schrieb Davey Shafik:
It would be best to just kill the vote and start over. The proposal should
be for deprecation notice in 7.2 and implementation in 8.0 IMO — it should
be one vote, as doing both together should be the only option.
+1