Hi,
No, you're not misreading the subject line. I began working on the docs for
the previously accepted proposal and became uncomfortable with the
approach. I think it will be better to integrate this info into
PDOStatement::debugDumpParams(). It will let me do the testing I want to do
without introducing a new API, which was the primary concern expressed in
the previous discussion.
I reverted the code I'd committed, updated the RFC with an example, and
reset the vote:
https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation
Since this isn't a strong departure from the original RFC, I don't think
another discussion period is necessary. Please let me know if you disagree.
Otherwise, voting will end on 30 November 2016 at 0:00 UTC.
Previous discussion occurred in these threads:
http://marc.info/?l=php-internals&m=147638162506291&w=2
http://marc.info/?l=php-internals&m=147734024403899&w=2
http://marc.info/?l=php-internals&m=147673258418764&w=2
Thanks for your patience as I get acclimated to the world of RFCs.
Adam
Morning Adam,
Once the proposal had been accepted, and merged, it's not really legitimate
to unilaterally decide that it's a bad implementation and revert it
yourself.
In addition, what we are looking at is a new RFC, that uses some of the
same words as the old one, but a different approach and a different
implementation.
Please start the discussion period from the beginning.
Please do not revert patches that were voted in by the community without
consensus.
Cheers
Joe
Hi,
No, you're not misreading the subject line. I began working on the docs for
the previously accepted proposal and became uncomfortable with the
approach. I think it will be better to integrate this info into
PDOStatement::debugDumpParams(). It will let me do the testing I want to
do
without introducing a new API, which was the primary concern expressed in
the previous discussion.I reverted the code I'd committed, updated the RFC with an example, and
reset the vote:
https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulationSince this isn't a strong departure from the original RFC, I don't think
another discussion period is necessary. Please let me know if you disagree.
Otherwise, voting will end on 30 November 2016 at 0:00 UTC.Previous discussion occurred in these threads:
http://marc.info/?l=php-internals&m=147638162506291&w=2
http://marc.info/?l=php-internals&m=147734024403899&w=2
http://marc.info/?l=php-internals&m=147673258418764&w=2Thanks for your patience as I get acclimated to the world of RFCs.
Adam
Once the proposal had been accepted, and merged, it's not really
legitimate to unilaterally decide that it's a bad implementation and revert
it yourself.
That's fair. I will revert the revert and open a new RFC to supersede the
previous one. Thanks again for your patience.
Adam
Hi!
Hi,
No, you're not misreading the subject line. I began working on the docs for
the previously accepted proposal and became uncomfortable with the
approach. I think it will be better to integrate this info into
PDOStatement::debugDumpParams(). It will let me do the testing I want to do
without introducing a new API, which was the primary concern expressed in
the previous discussion.I reverted the code I'd committed, updated the RFC with an example, and
reset the vote:
https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation
I don't think this is how RFC process is supposed to work. If the
proposal is not mature enough, it should be discussed or worked on more.
Committing it, then reverting it and immediately starting another vote
is definitely not what should be done. It looks highly irregular and
suggests that this is not mature enough. Also, jumping right into the
vote is definitely not how it should work. If anything, more discussion
period is needed to see why the approach that was accepted is not good
enough, and to ensure the errors made on the previous one are not repeated.
Stas Malyshev
smalyshev@gmail.com