On 10/25/2012 12:36 AM, Kris Craig wrote:
On Wed, Oct 24, 2012 at 11:21 PM, Sherif Ramadan <theanomaly...@gmail.com>wrote:
On Thu, Oct 25, 2012 at 1:46 AM, JJ <ja...@php.net> wrote:
On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan
<theanomaly...@gmail.com> wrote:
I understand there are people out there that don't read the
documentation and aren't aware of the difference between
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); and curl_setopt($ch,
CURLOPT_SSL_VERIFYHOST, true); but still... I don't think this is a
good idea either.
I highly doubt code that sets CURLOPT_SSL_VERIFYHOST => true meant to
imply CURLOPT_SSL_VERIFYHOST => 1...which essentially bypasses host
verification.
That's not our place to start guessing what the user did or did not
intend. The fact remains that a cast of a boolean true to int is in
fact 1. The fact also remains that CURLOPT_SSL_VERIFYHOST expects an
int as per the documented behavior. The fact additionally remains that
no user would expect var_dump((int) true) to return int(2).
According to libcurl, CURLOPT_SSL_VERIFYHOST => 1 is "not ordinarily a
useful setting".
Again, you're confusing users who don't read documentation and/or
don't understand it with users who may have fully read documentation
and understood it perfectly well and ever intention of setting
CURLOPT_SSL_VERIFYHOST to 1.
I understand your intentions here are good, but we should not be
magically trying to guess what the user wants. We should document the
behavior clearly and this solution makes documentation completely
unclear. Nowhere in the PHP manual do we say "we might break the
promise of a boolean cast to int and make it int(2) instead of
int(1)".
- JJ
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Correct me if I'm wrong, but 2 is already the default value, right? I've
also seen plenty of cases where TRUE is mistakenly used instead of 2. I
would also agree that this behavior is somewhat counter-intuitive.
However, I think we'd be opening a can of worms if we started making
arbitrary tweaks to change the documented behavior of third-party
libraries. I think you do make a very good case for changing this
behavior, but that case would (in my opinion, at least) need to be made to
the folks over at libcurl, not here.
That said, I can't think of any rational use-case for passing TRUE instead
of 1. Every time I've seen this, the intended behavior was 2.
What if, instead of changing the behavior, we have it throw a notice or
warning if a boolean value is passed here? Because this is such a common
error, I think it could be really beneficial in helping developers catch
this early. Thoughts?
--Kris
So you propose to implement strict type checking of parameters because a
few bozos don't read the documentation? That doesn't make much sense to me.
What makes more sense is that the extension perform its own type
checking where that is appropriate. I have plenty of subroutine code
that checks what it was passed, it isn't difficult to do the job right
instead of twiddling the language every time somebody complains.
And by the way, is there any effort in-progress to make the basic
subroutine calls more uniform, or are is_array() and isset() and friends
going to forever remain underscore versus non-underscore?
Perhaps I have no clue, but it sounded as though the language was to be
changed to "fix" an error in an extension, 'scuse me if I'm talking out
of my nether orifice.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
