RE: [PHP] odd behavior of stripos() with === operator *LAST POST*

Logic dictates that if something evaluates to NOT FALSE it
must be TRUE.

In a situation where you are only dealing with boolean values, that above
statement would be correct. In this case it is not.

int stripos ( string haystack, string needle [, int offset] )

What you are missing here is the fact that this function is designed to tell
you the position of the needle in your haystack, thus it returns an integer
value unless the string is not found.

Since 0 is a valid position and 0 does not evaluate to TRUE, you cannot
check for a TRUE condition. You must check for "NOT FALSE".

I think the way you are using this function is to simply see if the needle
is contained within the haystack.


function found_in_string($haystack, $needle) {
$retval = FALSE;
if (stripos($haystack, $needle) !== FALSE) {
$retval = TRUE;
}
return $retval;
}

This function would return only TRUE or FALSE, thus you could conclude that
if the return value is NOT FALSE it _must_ be TRUE.


I hope that helps clarify a bit.

-B


-----Original Message-----
From: Ford, Mike [mailto:M.Ford@xxxxxxxxxxxxxx]
Sent: Friday, November 17, 2006 7:15 AM
To: Michael
Cc: php-general@xxxxxxxxxxxxx
Subject: RE: [PHP] odd behavior of stripos() with === operator *LAST POST*

On 17 November 2006 09:55, Michael wrote:

This will be my last post on this thread of discussion.

Thanks to all who replied, I have it figured out.

I guess my only problem with the way the !== and ===
operators work in this situation is this:

Logic dictates that if something evaluates to NOT FALSE it
must be TRUE.

Um, yes, but it's the *test* that's evaluating to NOT FALSE (and obeys
this rule), which says nothing about the actual values involved in the
test. Even with the != operator you can demonstrate this point:

$x = "yes";
if ($x!=FALSE) { echo "\$x must be TRUE" }

will display the message, even though $x contains the string "yes"
(because the string "yes" in a Boolean context evaluates to TRUE).

if !== evaluates to TRUE then === should also under the same
conditions (all other things being equal)

I don't think that's quite what you meant, but I think I understand the
point you were getting at, and it's not valid. If something !==FALSE,
then TRUE is one of the values it may be === to -- but so are all the
integers, all the floating numbers, all the strings, all possible objects,
....

In other words, if $x!==FALSE, it *might* be ===TRUE, but it *might* also
be ===0, ===1, ===1.0 (not the same as 1!), ==="hello world", etc.

The *test* *itself*, however, would obey that rule -- that the *test*
returns a Boolean value says nothing about the types of its operands.

if !== evaluates an integer 0 to TRUE, so should ===

Neither of them can evaluate an integer 0 to TRUE, as 0 and TRUE are
different types. You're confusing how these operators evaluate their
operands with the resulting value of the test: the === and !== operators
will both evaluate an integer 0 as 0 -- it's the result of the test that
will be strictly either TRUE or FALSE. (As it happens, 0 and FALSE also
give different values when evaluated by ==/!=, so you'd have the same
conceptual problem with those operators).

, it
can't be true and still return a false value. The !== and ===
operators work differently, they should be complimentary.

No, they work exactly the same. Both of them *first* look at the types of
the two values, and *if and only if* the types are the same are the values
compared.

So: 0!==FALSE will succeed immediately, returning TRUE, because the types
differ
and: 0===FALSE will fail immediately, returning FALSE, because the types
differ

which are as you expected the complementary Boolean values.

*However*:

1!==FALSE returns TRUE by the same logic, and
1===TRUE returns the complementary FALSE

Immediately, then, you can see that we have two values that are both
!==FALSE, and yet neither of them is the value TRUE.

I'm afraid I've gone on at some length here, but I felt throughout this
thread that you really hadn't grasped the underlying conceptual point, and
I hope some of my examples may have helped illuminate it for you.

Cheers!

Mike

---------------------------------------------------------------------
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: m.ford@xxxxxxxxxxxxxx
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211


To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

.

Relevant Pages