Bug #62987 [Opn]: Assigning to ArrayObject[null][something] overrides all undefined variables
Edit report at https://bugs.php.net/bug.php?id=62987&edit=1
ID: 62987
User updated by:danko at very dot lv
Reported by:danko at very dot lv
-Summary:Assigning to ArrayObject[null][something] creates
phantom keys in all arrays
+Summary:Assigning to ArrayObject[null][something] overrides
all undefined variables
Status: Open
Type: Bug
Package:SPL related
Operating System: Linux
PHP Version:5.4Git-2012-08-31 (Git)
Block user comment: N
Private report: N
New Comment:
Forget about arrays. It just dawned on me that *everything undefined* is
affected.
var_dump($nothing);
var_dump($a->nothing);
string(6) "srsly?"
string(6) "srsly?"
Previous Comments:
[2012-08-31 21:05:35] danko at very dot lv
A bit different behavior shows in older versions.
See http://codepad.org/RBPih545 for example (don't know their version, but
older than 5.4, obviously)
--------
[2012-08-31 20:57:44] danko at very dot lv
Description:
Basically, when you try to assign anything to ArrayObject[null]['any_key'], it
fails as it should, but since that moment anytime you access a non-existing key
in any array, you get the last created zval, or so it seems.
Strangely enough, all warnings and notices are shown and isset() returns false.
Test script:
---
string(4) "durr"
}
array(1) {
["hurr"]=>
string(4) "durr"
}
array(1) {
["hurr"]=>
string(4) "durr"
}
array(0) {
}
array(0) {
}
string(6) "srsly?"
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62987&edit=1
Bug #62987 [Com]: Assigning to ArrayObject[null][something] creates phantom keys in all arrays
Edit report at https://bugs.php.net/bug.php?id=62987&edit=1
ID: 62987
Comment by: danko at very dot lv
Reported by:danko at very dot lv
Summary:Assigning to ArrayObject[null][something] creates
phantom keys in all arrays
Status: Open
Type: Bug
Package:SPL related
Operating System: Linux
PHP Version:5.4Git-2012-08-31 (Git)
Block user comment: N
Private report: N
New Comment:
A bit different behavior shows in older versions.
See http://codepad.org/RBPih545 for example (don't know their version, but
older than 5.4, obviously)
Previous Comments:
[2012-08-31 20:57:44] danko at very dot lv
Description:
Basically, when you try to assign anything to ArrayObject[null]['any_key'], it
fails as it should, but since that moment anytime you access a non-existing key
in any array, you get the last created zval, or so it seems.
Strangely enough, all warnings and notices are shown and isset() returns false.
Test script:
---
string(4) "durr"
}
array(1) {
["hurr"]=>
string(4) "durr"
}
array(1) {
["hurr"]=>
string(4) "durr"
}
array(0) {
}
array(0) {
}
string(6) "srsly?"
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62987&edit=1
[PHP-BUG] Bug #62987 [NEW]: Assigning to ArrayObject[null][something] creates phantom keys in all arrays
From: danko at very dot lv
Operating system: Linux
PHP version: 5.4Git-2012-08-31 (Git)
Package: SPL related
Bug Type: Bug
Bug description:Assigning to ArrayObject[null][something] creates phantom keys
in all arrays
Description:
Basically, when you try to assign anything to ArrayObject[null]['any_key'],
it fails as it should, but since that moment anytime you access a
non-existing key in any array, you get the last created zval, or so it
seems.
Strangely enough, all warnings and notices are shown and isset() returns
false.
Test script:
---
string(4) "durr"
}
array(1) {
["hurr"]=>
string(4) "durr"
}
array(1) {
["hurr"]=>
string(4) "durr"
}
array(0) {
}
array(0) {
}
string(6) "srsly?"
bool(false)
--
Edit bug report at https://bugs.php.net/bug.php?id=62987&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62987&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62987&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62987&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62987&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62987&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62987&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62987&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62987&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62987&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62987&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62987&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62987&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62987&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62987&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62987&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62987&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62987&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62987&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62987&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62987&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62987&r=mysqlcfg
Req #54243 [Com]: Shorter syntax for closures
Edit report at https://bugs.php.net/bug.php?id=54243&edit=1
ID: 54243
Comment by: danko at very dot lv
Reported by:anil at saog dot net
Summary:Shorter syntax for closures
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Um, no, *that* is unreadable. The original syntax can easily be made readable
if you do care:
$myObject->MyMethod(
'abc',
function ($a) use ($b) {
return $a == $b;
}
);
There you go. As readable as it gets - just add some newlines and tabs. On the
other hand, a soup of brackets and dollar signs can't be readable regardless of
formatting.
Previous Comments:
[2011-03-13 16:16:45] anil at saog dot net
Changed package
[2011-03-13 16:09:36] anil at saog dot net
Description:
Current closure syntax makes the code a little bit unreadable and also
shortening the syntax of a handy thing like this seems more logical.
Test script:
---
As of now "closure" syntax is:
function ($a) use($b){ return $a == $b; }
Passing a closure to any other scope:
$myObject = new myObject ();
$myObject->MyMethod('abc', function ($a) use($b){ return $a == $b; });
Expected result:
My short syntax candidate is:
$([arg1],[arg2],[arg...], {[method body]},
[scope_var1],[scope_var2],[scope_var...])
So passing with use token syntax:
$myObject = new myObject ();
$myObject->MyMethod('abc', $($a, {$a == $b}, $b));
Without "use" token:
$myObject = new myObject ();
$myObject->MyMethod('abc', $($a, {$a == $b}));
With more than one method argument:
$myObject = new myObject ();
$myObject->MyMethod('abc', $($a,$k,$p,{$a == $b}));
--
Edit this bug report at https://bugs.php.net/bug.php?id=54243&edit=1
Bug #61422 [Opn]: Lack of autoload on type hinting breaks class_alias
Edit report at https://bugs.php.net/bug.php?id=61422&edit=1 ID: 61422 User updated by:danko at very dot lv Reported by:danko at very dot lv Summary:Lack of autoload on type hinting breaks class_alias Status: Open Type: Bug Package:SPL related Operating System: Linux PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Sorry, what I meant in the last example is // Create a Demo object using "Y", // and pass that to function expecting "X" Previous Comments: ---- [2012-03-16 21:06:27] danko at very dot lv Description: I found #39003 which implies that autoload *was* called for type hinting previously and called for removal of this "unnecessary" feature. I beg to differ. Our framework depends on using class_alias to provide a dynamic modular structure, and one real class may have multiple aliases depending on situation, and these aliases are currently added when needed. Therefore, if an object is creating using alias X (or no alias at all) and is passed to a function expecting the same class under alias Y (and no object was created using that alias) a completely invalid fatal error is raised (see a simplified demo below). I would also like to point out, that if after calling autoload it turns out that it was not, in fact, an alias, the call will fatally fail anyway, so a really useless autoload will be only called once. I don't see any "resource consumption" problem here. Test script: --- https://bugs.php.net/bug.php?id=61422&edit=1
[PHP-BUG] Bug #61422 [NEW]: Lack of autoload on type hinting breaks class_alias
From: Operating system: Linux PHP version: 5.4.0 Package: SPL related Bug Type: Bug Bug description:Lack of autoload on type hinting breaks class_alias Description: I found #39003 which implies that autoload *was* called for type hinting previously and called for removal of this "unnecessary" feature. I beg to differ. Our framework depends on using class_alias to provide a dynamic modular structure, and one real class may have multiple aliases depending on situation, and these aliases are currently added when needed. Therefore, if an object is creating using alias X (or no alias at all) and is passed to a function expecting the same class under alias Y (and no object was created using that alias) a completely invalid fatal error is raised (see a simplified demo below). I would also like to point out, that if after calling autoload it turns out that it was not, in fact, an alias, the call will fatally fail anyway, so a really useless autoload will be only called once. I don't see any "resource consumption" problem here. Test script: --- https://bugs.php.net/bug.php?id=61422&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61422&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61422&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61422&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61422&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61422&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61422&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61422&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61422&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61422&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61422&r=support Expected behavior: https://bugs.php.net/fix.php?id=61422&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61422&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61422&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61422&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61422&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61422&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61422&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61422&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61422&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61422&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61422&r=mysqlcfg
