Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:18454
Return-Path: <andi@zend.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 70905 invoked by uid 1010); 25 Aug 2005 23:16:13 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 70890 invoked from network); 25 Aug 2005 23:16:13 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 25 Aug 2005 23:16:13 -0000
X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4)
Received: from ([80.74.107.235:39131] helo=mail.zend.com)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id 30/04-28235-C315E034 for <internals@lists.php.net>; Thu, 25 Aug 2005 19:16:13 -0400
Received: (qmail 15979 invoked from network); 25 Aug 2005 23:16:06 -0000
Received: from localhost (HELO ANDI-NOTEBOOK.zend.com) (127.0.0.1)
	by localhost with SMTP; 25 Aug 2005 23:16:06 -0000
Message-ID: <6.2.3.4.2.20050825161501.04ef2100@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Thu, 25 Aug 2005 16:15:57 -0700
To: Marcus Boerger <helly@php.net>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>,internals <internals@lists.php.net>,
	Stanislav Malyshev <stas@zend.com>
In-Reply-To: <1101007293.20050825091454@marcus-boerger.de>
References: <430CEA87.7040805@lerdorf.com>
	<6.2.3.4.2.20050824163046.05e01330@localhost>
	<1101007293.20050825091454@marcus-boerger.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Schroedinger Objects
From: andi@zend.com (Andi Gutmans)

Yep, the default for an instantiated object should be true (i.e. it's 
not null).

Andi

At 12:14 AM 8/25/2005, Marcus Boerger wrote:
>Hello Andi,
>
>   in that case we are providing a default conversion, maybe like the old
>one? Or just always return 1 like we do in 5.0 ?
>
>marcus
>
>Thursday, August 25, 2005, 1:31:08 AM, you wrote:
>
> > Yep I think that's a good point.
> > Checking for cast is the right thing IMO.
>
> > At 02:45 PM 8/24/2005, Rasmus Lerdorf wrote:
> >>As per bug #34199 and as Rob points out, if($obj) and if(!$obj) are
> >>handled by different opcodes and these two opcodes are inconsistent in
> >>whether they call an object's cast_object handler.
> >>
> >>if($obj) results in a ZEND_JMPZ_SPEC_CV_HANDLER which calls
> >>i_zend_is_true() which always return true for objects, no matter what
> >>(ignore compatibility mode here) because of this code in zend_execute.h:
> >>
> >>         case IS_OBJECT:
> >>             if(IS_ZEND_STD_OBJECT(*op)) {
> >>                 TSRMLS_FETCH();
> >>                 if(EG(ze1_compatibility_mode)) {
> >>                     result =
> >> (zend_hash_num_elements(Z_OBJPROP_P(op))?1:0);
> >>                 } else {
> >>                     result = 1;
> >>                 }
> >>             } else {
> >>                 result = 1;
> >>             }
> >>             break;
> >>
> >>if(!$obj) results in a which calls convert_to_boolean() which in turn
> >>calls convert_object_to_type() which has:
> >>
> >>if (Z_OBJ_HT_P(op)->cast_object) {
> >>
> >>     if (Z_OBJ_HT_P(op)->cast_object(op, op, ctype, 1 TSRMLS_CC) ==
> >>SUCCESS) {
> >>          op->type = ctype;
> >>
> >>     }
> >>
> >>This means that any object which actually implements a cast_object
> >>handler that returns false under some condition will be broken.  The
> >>simple example is:
> >>
> >>   $a = simplexml_load_string('<a></a>');
> >>   if($a && !$a) echo "BUG!";
> >>
> >>I think we need to fix i_zend_is_true's IS_OBJECT case to check to see
> >>if the object has a cast_object handler and call it or just call
> >>convert_to_boolean() there.  Or we need to clean this up and not have
> >>such different codepaths for these two cases.