#34934 [NEW]: offsetExists not called in dreived class
From: adove at booyahnetworks dot com Operating system: WinXP, Linux PHP version: 5.0.5 PHP Bug Type: SPL related Bug description: offsetExists not called in dreived class Description: I've searched the bug list and found only one bug that hints arond the same issue (http://bugs.php.net/bug.php?id=34849) BUT it appears the closing statement in the bug ArrayAccess objects don't work in array_*() functions. You may want to turn this report into a feature request? seems incorrect per the code below. I have an class (MyArray) I derived from ArrayObject and have overridden the ArrayAccess::offset* methods to allow me to make the array addressable via an XPath-styled key path, e.g., /key1/key2, etc.). All of the offset* methods get called just fine and work like a champ EXCEPT offsetExists... Based on the bug ref'd above, offsetExists is just an adjunct function on the ArrayAccess interface and not hooked up to any language constructs. HOWEVER, based on emperical information, this appears incorrect/inconsistent. The code submited illustrates the point. If I take a raw ArrayObject, set it to a multi-dim'd array and test for the root key via array_key_exists, I get true, which is correct. Additionally, if I test for any other key I get false, which is also correct. Based on the above bug I would expect to get a warning about only arrays being passed to the method blah blah. So, somehow it would *appear* that the ArrayObject class is somehow having its offsetExists method. When I do the same tests with my derived array object (MyArray), I get the same results. HOWEVER, my overidden offsetExists method is never called. This is evident via debuging (I never step into it) and in the last test assigned to $bShouldWorkButDoesNot. This path actually does exist and would have been confirmed to via my offsetExists. So, I am prepared to be given the same answer as the other bug. ;-) BUT, I think this is inconsistent behavior so it seems a bug to me... And, if it is not a bug, then I will 100% submit a feature request. Reproduce code: --- $a = array( test = array( one = dunno, two = array( peekabo = do you see me?, anyone = array(there) ) ) ); $oArray = new ArrayObject($a); $oMyArray = new MyArray($a); $bWorks1 = array_key_exists(test, $oArray); $bWorks2 = array_key_exists(test, $oMyArray); $bShouldWorkButDoesNot = array_key_exists(test/two/peekabo, $oBooyahArray); Expected result: true === $bWorks1 true === $bWorks2 true === $bShouldWorkButDoesNot Actual result: -- true === $bWorks1 true === $bWorks2 false === $bShouldWorkButDoesNot -- Edit bug report at http://bugs.php.net/?id=34934edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34934r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34934r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34934r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34934r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34934r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34934r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34934r=needscript Try newer version: http://bugs.php.net/fix.php?id=34934r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34934r=support Expected behavior: http://bugs.php.net/fix.php?id=34934r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34934r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34934r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34934r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34934r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34934r=dst IIS Stability: http://bugs.php.net/fix.php?id=34934r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34934r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34934r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34934r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34934r=mysqlcfg
#34934 [Fbk-Opn]: offsetExists not called in derived class
ID: 34934 User updated by: adove at booyahnetworks dot com -Summary: offsetExists not called in dreived class Reported By: adove at booyahnetworks dot com -Status: Feedback +Status: Open Bug Type: SPL related Operating System: WinXP, Linux PHP Version: 5.0.5 New Comment: Same behavior in both the latest 5.0.5 and 5.1... Previous Comments: [2005-10-20 18:57:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-10-20 18:52:00] adove at booyahnetworks dot com Description: I've searched the bug list and found only one bug that hints arond the same issue (http://bugs.php.net/bug.php?id=34849) BUT it appears the closing statement in the bug ArrayAccess objects don't work in array_*() functions. You may want to turn this report into a feature request? seems incorrect per the code below. I have an class (MyArray) I derived from ArrayObject and have overridden the ArrayAccess::offset* methods to allow me to make the array addressable via an XPath-styled key path, e.g., /key1/key2, etc.). All of the offset* methods get called just fine and work like a champ EXCEPT offsetExists... Based on the bug ref'd above, offsetExists is just an adjunct function on the ArrayAccess interface and not hooked up to any language constructs. HOWEVER, based on emperical information, this appears incorrect/inconsistent. The code submited illustrates the point. If I take a raw ArrayObject, set it to a multi-dim'd array and test for the root key via array_key_exists, I get true, which is correct. Additionally, if I test for any other key I get false, which is also correct. Based on the above bug I would expect to get a warning about only arrays being passed to the method blah blah. So, somehow it would *appear* that the ArrayObject class is somehow having its offsetExists method. When I do the same tests with my derived array object (MyArray), I get the same results. HOWEVER, my overidden offsetExists method is never called. This is evident via debuging (I never step into it) and in the last test assigned to $bShouldWorkButDoesNot. This path actually does exist and would have been confirmed to via my offsetExists. So, I am prepared to be given the same answer as the other bug. ;-) BUT, I think this is inconsistent behavior so it seems a bug to me... And, if it is not a bug, then I will 100% submit a feature request. Reproduce code: --- $a = array( test = array( one = dunno, two = array( peekabo = do you see me?, anyone = array(there) ) ) ); $oArray = new ArrayObject($a); $oMyArray = new MyArray($a); $bWorks1 = array_key_exists(test, $oArray); $bWorks2 = array_key_exists(test, $oMyArray); $bShouldWorkButDoesNot = array_key_exists(test/two/peekabo, $oBooyahArray); Expected result: true === $bWorks1 true === $bWorks2 true === $bShouldWorkButDoesNot Actual result: -- true === $bWorks1 true === $bWorks2 false === $bShouldWorkButDoesNot -- Edit this bug report at http://bugs.php.net/?id=34934edit=1
#34934 [Fbk-Opn]: offsetExists not called in derived class
ID: 34934
User updated by: adove at booyahnetworks dot com
Reported By: adove at booyahnetworks dot com
-Status: Feedback
+Status: Open
Bug Type: SPL related
Operating System: WinXP, Linux
PHP Version: 5.0.5
New Comment:
Here's a full code sample to replicate. Note I stripped out the method
comments. If you want them I can repost.
?php
class MyArray extends ArrayObject
{
function __construct(
$mValue = array()
)
{
// Convert our value.
if(is_array($mValue))
{
$mValue = $this-recurs($mValue);
}
elseif(is_object($mValue) ($mValue instanceof ArrayObject))
{
// Get the raw array from our ArrayObject for handling.
$mValue = $this-recurs($mValue-getArrayCopy(),
$constFlags);
}
elseif(null == $mValue)
{
$mValue = array();
}
elseif(!is_object($mValue))
{
// Turn primative into an indexed array.
$mValue = array($mValue);
}
// else - it's an object, enum its public properites.
parent::__construct($mValue);
}
protected function explodeKeyPath($mKeyPath)
{
return explode(/, trim($mKeyPath, /));
}
function offsetSet($mKey, $mValue)
{
$mKey = trim($mKey, /);
if(stristr($mKey, /))
{
// A path was requested. Start out pointing to ourself.
$mRetval = $this;
$aKeyPathParts = $this-explodeKeyPath($mKey);
// Need to take the LAST path off. That's what we assign
our value too.
$strLastPathPart = array_pop($aKeyPathParts);
foreach($aKeyPathParts as $strPathPart)
{
// We know we our data are either a primative type or an
ArrayAccess.
if(($mRetval instanceof ArrayAccess)
array_key_exists($strPathPart, $mRetval)
)
{
$mRetval = $mRetval[$strPathPart];
}
else
{
// Need a new empty one of us and then point to
it!
$mRetval[$strPathPart] =
$this-newArrayObject($strPathPart, array(),
$this-getFlags());
$mRetval = $mRetval[$strPathPart];
}
}
// Now put our value!
$mRetval[$strLastPathPart] = $mValue;
}
else
{
if(is_array($mValue))
{
// Need to create a new instance of us!
$mValue = $this-newArrayObject($mKey, $mValue,
$this-getFlags());
}
parent::offsetSet($mKey, $mValue);
}
}
function offsetGet($mKey)
{
$mRetval = null;
$mKey = trim($mKey, /);
if(stristr($mKey, /))
{
// A path was requested. Start out pointing to ourself.
$mRetval = $this;
$aKeyPathParts = $this-explodeKeyPath($mKey);
foreach($aKeyPathParts as $strPathPart)
{
// We know we our data are either a primative type or an
ArrayAccess.
if(($mRetval instanceof ArrayAccess)
array_key_exists($strPathPart, $mRetval)
)
{
$mRetval = $mRetval[$strPathPart];
}
else
{
$mRetval = null;
break;
}
}
}
else
{
$mRetval = parent::offsetGet($mKey);
}
return $mRetval;
}
function offsetUnset($mKey)
{
$mKey = trim($mKey, /);
if(stristr($mKey, /))
{
// A path was requested. Start out pointing to ourself.
$oArray = $this;
$aKeyPathParts = $this-explodeKeyPath($mKey);
// Need to take the LAST path off. That's what we unset.
$strLastPathPart = array_pop($aKeyPathParts);
foreach($aKeyPathParts as $strPathPart)
{
// We know we our data are either a primative type or an
ArrayAccess.
if(($oArray instanceof ArrayAccess)
array_key_exists($strPathPart, $oArray)
)
{
$oArray = $oArray[$strPathPart];
}
else
#34816 [NEW]: Inconsitent behavior in ArrayObject for multi-dimensional data
From: adove at booyahnetworks dot com
Operating system: WinXP
PHP version: 5.1.0RC1
PHP Bug Type: SPL related
Bug description: Inconsitent behavior in ArrayObject for multi-dimensional data
Description:
If you create an ArrayObject with mutli-dimensional array data, you can
access unique element paths fine but you can not change/add any
multi-dimensional paths due to the dreaded Fatal error: Objects used as
arrays in post/pre increment/decrement must return values by reference
error. Note this happens in BOTH 5.0.5 AND 5.1.0RC1.
IMHO, either the documentation for ArrayObject should clearly indicate
that it supports uni-dimenisional data get/set and ONLY get for
multi-dimensional. OR, the object walk the passed data and turn all arrays
into ArrayObject instances?
Reproduce code:
---
$a = array(
test = array(
one = dunno,
two = array(
peekabo = do you see me?,
anyone = array(there)
)
)
);
$oArray = new ArrayObject($a);
var_dump($oArray);
echo \n\\test\\one == . $oArray[test][one] . \n\n;
// NEITHER of the two below will work!
$oArray[test][one] = Yes I do!;
$oArray[test][yes] = array(
hello = Goodbye!
);
var_dump($oArray);
Expected result:
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) dunno
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
}
}
\test\one == dunno
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) Yes I do!
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
[yes]=
array(1) {
[hello]=
string(8) Goodbye!
}
}
}
Actual result:
--
object(ArrayObject)#1 (1) {
[test]=
array(2) {
[one]=
string(5) dunno
[two]=
array(2) {
[peekabo]=
string(14) do you see me?
[anyone]=
array(1) {
[0]=
string(5) there
}
}
}
}
\test\one == dunno
Fatal error: Objects used as arrays in post/pre increment/decrement must
return values by reference in array_obje_test.php on line 16
--
Edit bug report at http://bugs.php.net/?id=34816edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34816r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34816r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34816r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34816r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34816r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34816r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34816r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34816r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34816r=support
Expected behavior: http://bugs.php.net/fix.php?id=34816r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34816r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34816r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34816r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34816r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34816r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34816r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34816r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34816r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34816r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34816r=mysqlcfg
#31976 [NEW]: Accessing overloaded member via foreach does not work
From: adove at booyahnetworks dot com
Operating system: WinXP
PHP version: 5.0.3
PHP Bug Type: Zend Engine 2 problem
Bug description: Accessing overloaded member via foreach does not work
Description:
Using an overloaded property from an object instance directly in a foreach
fails. If you assign the property (or a reference to it) to a variable
first it works fine. This is reproducable.
Interestingly enough, I see a strange problem with inheritance and
overloaded members. I am unable to reproduce it in a simple example. I
will continue to work that. Basically, you get the same fatal error as
here BUT on assignment to a member variable of the parent class that is
not overloaded. It's bizzare. As soon as I remove the __get/__set from the
child, the parent method works fine again from an instance of child. Again,
simple examples do not seem to reproduce. sigh
Reproduce code:
---
class Son
{
protected $m_aActions;
function __construct($aActions)
{
$this-m_aActions = $aActions;
}
function __get($mName)
{
$mRetval = null;
switch($mName)
{
case(Actions):
{
$mRetval = $this-m_aActions;
break;
}
}
return $mRetval;
}
}
$aActions = array(add, delete);
$oSon = new Son($aActions);
$aActions = $oSon-Actions;
var_dump($aActions);
foreach($oSon-Actions as $strAction)
{
echo $strAction . \n;
}
Expected result:
array(2) {
[0]=
string(3) add
[1]=
string(6) delete
}
add
delete
Actual result:
--
array(2) {
[0]=
string(3) add
[1]=
string(6) delete
}
Fatal error: Cannot access undefined property for object with overloaded
property access
--
Edit bug report at http://bugs.php.net/?id=31976edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31976r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31976r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31976r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31976r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31976r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31976r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31976r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31976r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31976r=support
Expected behavior: http://bugs.php.net/fix.php?id=31976r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31976r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31976r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31976r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31976r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31976r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31976r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31976r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31976r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31976r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31976r=mysqlcfg
