[RFC][VOTE] Strict Argument Count On Function Calls

9 years ago by Marcio Almada — view source

unread

Hi,

The "Strict Argument Count" RFC is now on voting phase:

RFC: https://wiki.php.net/rfc/strict_argcount
PR: https://github.com/php/php-src/pull/1108

The voting will close in exactly 14 days counting from now (using the
date/time from this email as a reference).

If you have any doubt about what was already discussed, please refer to
this aggregated markmail summary http://markmail.org/thread/ol5s2vhw35ac2px3

Please read the RFC with full attention and good voting! :)

Thanks,
Márcio

9 years ago by Marcio Almada — view source

unread

Hi,

I received some requests to update the RFC with more information about BC
breaks + possible minor adjustments regarding dynamic function calls. So I
decided to drop the current voting, while it's still on the beginning, to
properly update the RFC. We had 7 votes computed - 4 "yes" and 3 "no" votes.

If you already voted, don't worry, it's just some minor changes and the
voting will be restarted by the end of the day (March 15) so we don't loose
the schedule. Another email will follow with a summary of what changed.

Thanks for the comprehension.

2015-03-14 20:54 GMT-03:00 Marcio Almada marcio.web2@gmail.com:

Hi,

The "Strict Argument Count" RFC is now on voting phase:

RFC: https://wiki.php.net/rfc/strict_argcount
PR: https://github.com/php/php-src/pull/1108

The voting will close in exactly 14 days counting from now (using the
date/time from this email as a reference).

If you have any doubt about what was already discussed, please refer to
this aggregated markmail summary
http://markmail.org/thread/ol5s2vhw35ac2px3

Please read the RFC with full attention and good voting! :)

Thanks,
Márcio

9 years ago by Dan Ackroyd — view source

unread

Hi,

I received some requests to update the RFC with more information about BC
breaks + possible minor adjustments regarding dynamic function calls.

Please can you stop abusing the RFC process?

This RFC is attempting to change the language. You received the
information about the BC breaks weeks ago, they aren't new items that
you just heard about for the first time today.. You opened the voting
and then closed it immediately when you realised the vote wasn't going
to sail through.

You're now making changes to the RFC and proposing to re-open voting
on the same day. How are people meant to have time to read and think
about the changes?

It's also going to be impossible for people to try the patch out, or
to measure it for performance hit.

The problem this RFC fixes is not a big enough problem to justify
making decisions about the language at the last minute, particularly
as the last version of the RFC I read breaks a whole load of valid
code.

cheers
Dan

9 years ago by Marcio Almada — view source

unread

2015-03-15 8:33 GMT-03:00 Dan Ackroyd danack@basereality.com:

Hi,

I received some requests to update the RFC with more information about BC
breaks + possible minor adjustments regarding dynamic function calls.

Please can you stop abusing the RFC process?

This RFC is attempting to change the language. You received the
information about the BC breaks weeks ago, they aren't new items that
you just heard about for the first time today.. You opened the voting
and then closed it immediately when you realised the vote wasn't going
to sail through.

There is no abuse. This is not true, I truly received a suggestion from Bob
Weiland and decided to consider it.
4:3 is not a sign that a voting will pass or not, it's only 7 votes and we
usually get ~52 votes during
a 14 days voting period.

You're now making changes to the RFC and proposing to re-open voting
on the same day. How are people meant to have time to read and think
about the changes?

It's a minor change, as said before. This was the most prudent attitude.

It's also going to be impossible for people to try the patch out, or
to measure it for performance hit.

Performance has never been an issue with this RFC. You probably meant "bc
break" not "performance hit", and the suggested change about dynamic calls
Bob did, if accepted by, is a minor change that will actually reduce the BC
breaks not enlarge it.

The problem this RFC fixes is not a big enough problem to justify
making decisions about the language at the last minute, particularly
as the last version of the RFC I read breaks a whole load of valid
code.

A lot of people tell me the opposite. I listened to your opinion many times
and disagreed with it.
Please don't express your disagreement with the RFC by mixing it with false
accusations towards me.
There is a huge gap between both attitudes.

The disagreement is ok, but the false accusations coming from you make me
sad.

cheers
Dan

Marcio

9 years ago by Dan Ackroyd — view source

unread

Hi

It's also going to be impossible for people to try the patch out, or
to measure it for performance hit.

Performance has never been an issue with this RFC. You probably meant "bc
break" not "performance hit", and the suggested change about dynamic calls
Bob did, if accepted by, is a minor change that will actually reduce the BC
breaks not enlarge it.

The patch has a pretty major bug in it.

If the function is called dynamically first, and then called
statically the warning is not given. i.e. the code below gives an
error 50% of the time. This is why people need time to evaluate code,
and why opening a vote straight after you've made a change to how the
syntax works is really bad idea.

<?php

function bar($x) {
}

if (rand(0, 1)) {
$fn = 'bar';
$fn(4, 5);
}
bar(4, 5);

exit(0);

This was built off your branch with commit
6ca9d912c9aa8361852e979c172e57b011b91c16

cheers
Dan

9 years ago by Marcio Almada — view source

unread

Hi,

I had no time to reply all emails since yesterday, but right now we are
having a voting with 2 "yes" votes vs 16 "no" votes.

I think we all agree that the RFC won't pass and I'm withdrawing the RFC
for the following reasons:

The sooner we end the voting period the better for the PHP time line.
Since there is no motives to think the voting will flip, the best attitude
seems to be a withdraw.
We are having a lot of simultaneous voting right now and some voters
care to read all the RFCs. The proposed RFC is long, requires testing etc.
As it was already rejected, removing it from the list of RFCs in voting
phase might be beneficial to the voting process as it reduces the RFC
overload we are having because of the feature freeze.
Looking at the ML, there are many controversial points that were
raised, a lot of them since yesterday. Weather they are debatable or not,
all this controversy during voting phases is a bad thing (look at the
scalar type hints drama we had). So it's better to just put this to end and
move on.

Thanks for the votes, I'll try to reply to the emails anyway whenever
necessary :)
PS: I don't intend to propose this RFC again in the future as I already
have other more important RFCs planned for PHP 7.1

Thanks,
Márcio

9 years ago by Simon Schick — view source

unread

Hi, all

At first, Thanks for all your work put in here, Marcio. It gave me a new
hint for a possible code-failure.

FYI: PhpStorm lately added an inspector for that. Glad to see that move
after I heard that the RFC won't pass.
https://youtrack.jetbrains.com/issue/WI-14692

Bye,
Simon

On Mon, Mar 16, 2015 at 6:04 PM, Marcio Almada marcio.web2@gmail.com
wrote:

Hi,

I had no time to reply all emails since yesterday, but right now we are
having a voting with 2 "yes" votes vs 16 "no" votes.

I think we all agree that the RFC won't pass and I'm withdrawing the RFC
for the following reasons:

The sooner we end the voting period the better for the PHP time line.
Since there is no motives to think the voting will flip, the best
attitude
seems to be a withdraw.

We are having a lot of simultaneous voting right now and some voters
care to read all the RFCs. The proposed RFC is long, requires testing
etc.
As it was already rejected, removing it from the list of RFCs in voting
phase might be beneficial to the voting process as it reduces the RFC
overload we are having because of the feature freeze.

Looking at the ML, there are many controversial points that were
raised, a lot of them since yesterday. Weather they are debatable or
not,
all this controversy during voting phases is a bad thing (look at the
scalar type hints drama we had). So it's better to just put this to end
and
move on.

Thanks for the votes, I'll try to reply to the emails anyway whenever
necessary :)
PS: I don't intend to propose this RFC again in the future as I already
have other more important RFCs planned for PHP 7.1

Thanks,
Márcio

9 years ago by Pascal Martin — view source

unread

Le 16/03/2015 18:04, Marcio Almada a écrit :

I had no time to reply all emails since yesterday, but right now we are
having a voting with 2 "yes" votes vs 16 "no" votes.

I think we all agree that the RFC won't pass and I'm withdrawing the RFC

Hi,

Even though it's a bit too late: thanks for your work on this!

At AFUP, we were +1 (by a rather large margin) on the idea of checking
for additional arguments, considering it would help detect some
(possible) future bugs. Seems we were going on the opposite direction of
the votes on the RFC itself.

We didn't quite reach a consensus between notices and warnings, though
-- mostly because they would maybe have helped detect possible
future bugs.

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/