Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:18395
Return-Path: <helly@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 28918 invoked by uid 1010); 25 Aug 2005 07:16:58 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 28903 invoked from network); 25 Aug 2005 07:16:58 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 25 Aug 2005 07:16:58 -0000
X-Host-Fingerprint: 81.169.182.136 ajaxatwork.net Linux 2.4/2.6
Received: from ([81.169.182.136:44453] helo=strato.aixcept.de)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id 7E/C0-28235-7607D034 for <internals@lists.php.net>; Thu, 25 Aug 2005 03:16:56 -0400
Received: from [192.168.1.3] (dsl-082-083-233-023.arcor-ip.net [82.83.233.23])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by strato.aixcept.de (Postfix) with ESMTP id B38E635C36E;
	Thu, 25 Aug 2005 09:37:29 +0200 (CEST)
Date: Thu, 25 Aug 2005 09:14:54 +0200
Reply-To: Marcus Boerger <helly@php.net>
X-Priority: 3 (Normal)
Message-ID: <1101007293.20050825091454@marcus-boerger.de>
To: Andi Gutmans <andi@zend.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>,
	internals <internals@lists.php.net>,
	Stanislav Malyshev <stas@zend.com>
In-Reply-To: <6.2.3.4.2.20050824163046.05e01330@localhost>
References: <430CEA87.7040805@lerdorf.com>
	<6.2.3.4.2.20050824163046.05e01330@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Schroedinger Objects
From: helly@php.net (Marcus Boerger)

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.