Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72989
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.172 as permitted sender)
MIME-Version: 1.0
Date: Fri, 7 Mar 2014 18:14:18 +0800
Message-ID: <CAHMUw2GjeDRveLK99Q8U08y-3zqftAN8mLKPt=yikjT2BrNdBQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b66f5fb452d2604f4018406
Subject: [PR 614] ArrayObject and isset() / empty() behaviour
From: tjerk.meesters@gmail.com (Tjerk Meesters)

--047d7b66f5fb452d2604f4018406
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I come across the following bug: https://bugs.php.net/bug.php?id=66834

With an extended ArrayObject instance, the behaviour of `isset()` and
`empty()` is as follows:

1. Call `static::offsetExists()`
2. If return value is truthy, then
  a. isset() returns true
  b. empty() returns false
  c. spl_array_has_property() returns true

However, if the ArrayObject instance is not overridden:

1. Fetch value (either via string or long key)
2. If key is found, then:
  a. isset() returns false if value is `null`, true otherwise.
  b. empty() returns true if value is truty, false otherwise.
  c. spl_array_has_property() returns true

That's counterintuitive, so my patch addresses this by also calling
`offsetGet()` if applicable. I wanted to bring this to the attention of the
group first, because it may affect performance to achieve this goal:

https://github.com/php/php-src/pull/614

I've tried to contact Marcus Boerger, but I was told that he's been less
active lately. Let me know your thoughts. The patch targets 5.4 onwards.


-- 
--
Tjerk

--047d7b66f5fb452d2604f4018406--