Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55049 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55497 invoked from network); 1 Sep 2011 05:35:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Sep 2011 05:35:31 -0000 Authentication-Results: pb1.pair.com header.from=christian.stocker@liip.ch; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=christian.stocker@liip.ch; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain liip.ch designates 207.126.144.144 as permitted sender) X-PHP-List-Original-Sender: christian.stocker@liip.ch X-Host-Fingerprint: 207.126.144.144 eu1sys200aob118.obsmtp.com Linux 2.5 (sometimes 2.4) (4) Received: from [207.126.144.144] ([207.126.144.144:41119] helo=eu1sys200aob118.obsmtp.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F1/61-44095-2A91F5E4 for ; Thu, 01 Sep 2011 01:35:31 -0400 Received: from mail-fx0-f45.google.com ([209.85.161.45]) (using TLSv1) by eu1sys200aob118.postini.com ([207.126.147.11]) with SMTP ID DSNKTl8ZmHWwYrWhK86tGIdVPB66YA5ggLT5@postini.com; Thu, 01 Sep 2011 05:35:24 UTC Received: by fxbb27 with SMTP id b27so480897fxb.32 for ; Wed, 31 Aug 2011 22:35:20 -0700 (PDT) Received: by 10.223.68.136 with SMTP id v8mr1087522fai.54.1314855320608; Wed, 31 Aug 2011 22:35:20 -0700 (PDT) Received: from pri7.local (84-72-44-234.dclient.hispeed.ch [84.72.44.234]) by mx.google.com with ESMTPS id b13sm196399fak.40.2011.08.31.22.35.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Aug 2011 22:35:19 -0700 (PDT) Message-ID: <4E5F1996.4050002@liip.ch> Date: Thu, 01 Sep 2011 07:35:18 +0200 Organization: Liip AG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: PHPdev X-Enigmail-Version: 1.3.1 OpenPGP: id=0748D5FE; url=http://gpg-keyserver.de/pks/lookup?op=get&search=0xC2BAFBC30748D5FE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: simplexml inconsistencies in the last few releases (the same issue already discussed) From: christian.stocker@liip.ch (Christian Stocker) Hi It's about the two tests in http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/simplexml/tests/008.phpt and http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/simplexml/tests/bug48601.phpt which contractited themself and we had back and forth commits due to this. So we had the following history 5.3.0 old behaviour ... 5.3.3 new behaviour ... 5.3.7 old behaviour ... 5.4.0 new behaviour The main question now is, should we introduce back the new behavior in the 5.3 line? Since the new behaviour was already there since more than a year, but now isn't, i'm not sure, what to do. The good point about the new behaviour is that it's almost BC, so going from the old to the new shouldn't cause much problems, but vice versa it does. The reason is that if you do an valid xpath query which returns zero results, the old behaviour returned false, the new one returns an empty array, so before 5.3.3 you had to write *** $res = $sx->query("/some/xpath"); if ($res) { foreach($res as $node) {} } *** Which still will work with the new behaviour, but that "if" is not really needed with the new behaviour, so going back to the old one may break if nothing is found (there may be problems when you asked for "zero-results" with checking if $res is false) Anyway, I'd appreciate some opinions about introducing back the new beehaviour in 5.3 or not (I guess 5.3.8 wasn't the last 5.3 release :)) chregu -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE