> > 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: 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
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
