I used CVS to checkout 5.1.3RC3-dev and the problem has miraculously evaporated.

It's back!! Sorry, I previously wrote that this problem seemed to have disappeared when i updated to 5.1.3RC3-dev, but it is now back. The error I'm getting is:

Notice: Object of class Clause could not be converted to int in /usr/home/iain/public_html/vpc_test/packages/nozzle/db_object.class.php on line 2151

the line that is causing it is:

if($this->unique_clause == '')

This does not happen consistently everytime an object is used in a boolean expression and I am unable to create a simple test case that replicates the bug. ie. if you execute the following with php -f test.php:

<?
    class ClassOne
    {
        private $var;

        function ClassOne()
        {
            $this->var = 'some value';
        }
    }

$var = '';

if($var == '')
{
    echo('there is nothing there
');
}

$var = new ClassOne();

if($var == '')
{
    echo('there is still nothing there!
');
}

else
{
    echo('houston, we have no problem
');
}

die('done testing
');
?>

then you get:

> php -f test.php
there is nothing there
houston, we have no problem
done testing

as expected. It's difficult to know where to go from here because this is obviously a bug, because it is perfectly okay to use an object in a boolean expression, and this behaviour is _not_ exhibited in PHP 5.0.4, but I am unable to provide you with a simple test case that reproduces the bug.

A similar problem occurred in http://bugs.php.net/bug.php?id=33999, and it is supposedly fixed in CVS but it has apparently crept back in.

I have been able to hack in a fix for this in the code for 5.1.3RC3-dev with the following patch, which apparently just bypasses something called compatibility mode:

Index: zend_operators.c
===================================================================
RCS file: /repository/ZendEngine2/zend_operators.c,v
retrieving revision 1.208.2.4
diff -u -r1.208.2.4 zend_operators.c
--- zend_operators.c    5 Feb 2006 17:07:40 -0000       1.208.2.4
+++ zend_operators.c    7 Apr 2006 07:28:18 -0000
@@ -333,14 +333,15 @@
                                        return;
                                }

-                               if (EG(ze1_compatibility_mode)) {
+                               /*if (EG(ze1_compatibility_mode)) {*/
+                               else {
                                        HashTable *ht = Z_OBJPROP_P(op);
                                        if (ht) {
                                                retval = (zend_hash_num_elements(ht)?1:0);
                                        }
-                               } else {
+                               }/* else {
                                        zend_error(E_NOTICE, "Object of class %s could not be converted to int", Z_OBJCE_P(op)->name);
-                               }
+                               }*/
                                zval_dtor(op);
                                ZVAL_LONG(op, retval);
                                return;

By the way, enabling compatbility mode causes problems because then you cannot pass an object as the first argument of array_key_exists() which is unintuitive

Comparing objects or resources to strings, booleans and integers is obviously senseless.
This is expected behaviour.

Wrong, this is not expected, as http://bugs.php.net/bug.php?id=33999 states, and this same notice is also caused by:

if($obj1 == $obj2)

please do not dismiss a bug without properly understanding what is going on. if this is sensless then why doesn't it fail with the simple test case i provided?

haha i just notice that you (tony2001) were the one who stated: 

Dmitry, I guess we need to return at least objects index in  this case.
Or maybe use the same way we use when compatibility_mode is on.
What do you think?

which is clearly what my patch does, which has somehow been undone in later versions.

why would you dismiss such a thourough bug report as being senseless?? you could at least have the decency to forward it on to someone else.

>this same notice is also caused by:
>if($obj1 == $obj2)
Did you try it? Please try and see.

>please do not dismiss a bug without properly understanding
> what is going on.
Please don't claim anything if you didn't check it out yourself.

>if this is sensless then why doesn't it fail with the 
>simple test case i provided?

Because you're comparing objects to '', which is autoconverted to FALSE.
Try to compare objects to non-empty strings and you'll the expected warning.
It MAY change in the future, but this is not a bug, because comparing circles to squares doesn't make any sense.

Yes, the line:

if($this->top_reference == $ref)

also causes the error, and changing the code in zend_operators.c as i posted fixed the problem.

doing:

$var = FALSE;

if($some_other_var)
    $var = new SomeObject();

if($var)
    echo('we got here');

makes perfect sense, this is a bug.

this hasn't been assigned yet and it will be a real inconvenience if this is not fixed in the next major release.

as i've stated in the bug report, using the same behaviour in  zend_operators.c for function:

ZEND_API void convert_to_long_base(zval *op, int base)

for compatibility mode fixes this problem. the title of this bug report is "Cannot use an object with boolean expression", not "Cannot compare object to empty string". 

so far i don't think this issue has received the attention it requires.

<?php
class test {
}

$var = new test;

var_dump($var == "");
var_dump($var == "non-empty");
?>
works perfectly fine.

Yes, I had already stated that I could not recreate a simple test case, please read the entire bug report. I've also provided a hacked patch which stops the notice from appearing, although I'm informed by TML in ##php that what I have done is wrong, and doesn't actually 'fix' anything.

I've updated most of my code to use is_object instead of boolean comparisons to get around this, but it pops up from time to time.

I'm afraid the hacked patch won't help. 
ATM you're the only one person in this world who can reproduce it, so please provide a short but complete reproduce case.
Please reopen the report when you have it.
Thank you.