Edit report at https://bugs.php.net/bug.php?id=70118&edit=1
ID: 70118
User updated by: chealer at gmail dot com
Reported by: chealer at gmail dot com
Summary: PDOStatement::execute manual says "values are
treated as PDO::PARAM_STR"
Status: Re-Opened
Type: Documentation Problem
Package: Documentation problem
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you Tom.
I understand without effort the example you give. But I maintain that it is also technically
incorrect. Instead of:
"Enabling E_NOTICE during development has some benefits."
it would be more clear to state, for example:
"Enabling notices (with E_NOTICE) during development has some benefits."
Previous Comments:
------------------------------------------------------------------------
[2015-12-26 22:37:12] tpunt@php.net
Your stance is that constants should be replaceable by the integer value they're represented
by, and the sentence should still make sense.
By this notion, numerous other places in the manual are also incorrect. Take, for example, the
following sentence from the error reporting page[1]: "Enabling E_NOTICE during development has
some benefits." The constant E_NOTICE is represented by the integer value 8, and so the
sentence - from your stance - is nonsensical because you're saying that its equivalent to the
following sentence: "Enabling 8 during development has some benefits."
This is not true. The constant E_NOTICE has meaning to the developer because it *represents*
something. Replacing it with the value it is *represented by* will of course not make any sense, but
it shouldn't need to either. We don't care what value it is represented by, only the
meaning the constant has.
Anyway, I've reopened this at your request, but I still disagree with your opinion.
-Tom
[1]: http://php.net/error_reporting
------------------------------------------------------------------------
[2015-12-26 21:03:47] chealer at gmail dot com
I disagree. The sentence claims "All values are treated as PDO::PARAM_STR." Since
PDO::PARAM_STR is an integer, this needs to be valid if PDO::PARAM_STR is replaced by an integer.
Just like, if I claim that integers must be smaller than PHP_INT_MAX, it must be correct that
integer must be smaller than 2147483647 (or another integer).
Whether or not you consider this issue as a bug, please do reopen. The current situation is
definitely suboptimal.
------------------------------------------------------------------------
[2015-12-25 18:02:28] tpunt@php.net
We are not talking about what PDO::PARAM_STR is after it has been evaluated. We are talking about
what it *represents* ("the SQL CHAR, VARCHAR, or other string data type"). I still think
that this is therefore not a documentation problem.
If, however, you still disagree with me, then I will reopen this report and let another contributor
review it.
Thanks,
Tom
------------------------------------------------------------------------
[2015-12-24 20:27:28] chealer at gmail dot com
tpunt: technically, PDO::PARAM_STR *is* an integer.
There are strings in systems other than PHP, so the suggestion is valid, but feel free to be more
specific.
In any case, please explain why this was closed.
------------------------------------------------------------------------
[2015-12-19 18:00:07] tpunt@php.net
PDO::PARAM_STR does not *represent* an integer. It is *represented by* an integer, but it itself
represents "the SQL CHAR, VARCHAR, or other string data type"[1]. Given the
aforementioned, and that the default binding type is PDO::PARAM_STR, I still don't see the
sentence as being incorrect. If anything, I'd say it is more technically accurate than
mentioning "string", since we're not actually talking about strings in PHP, but
rather strings at the database level (like PDO::PARAM_NULL representing the SQL NULL data type,
rather than PHP's null).
[1]: http://uk1.php.net/manual/en/pdo.constants.php
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=70118
--
Edit this bug report at https://bugs.php.net/bug.php?id=70118&edit=1