Req #51808 [Com]: Operator `new' does not support expressions for class name
Edit report at http://bugs.php.net/bug.php?id=51808&edit=1
ID: 51808
Comment by: + at ni-po dot com
Reported by:m dot przybylski at bkfmyjnie dot pl
Summary:Operator `new' does not support expressions for
class name
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: linux/current
PHP Version:5.2.13
Block user comment: N
New Comment:
Imho this isn't obvious at all. At least your proposed syntax `new
(func())()` isn't quite readable or understandable.
Previous Comments:
[2010-05-13 12:53:31] m dot przybylski at bkfmyjnie dot pl
Description:
Operator `new' accepts either class name as either symbol token or
variable
containing class name (T_STRING or
T_VARIABLE), but does not allow expressions returning class name.
Test script:
---
/* first form, works */
$handler = new SomeClass($constructorParam);
/* second form, works */
$handlerClass = handlerFor($something); /* returns name of some class to
be instantiated */
$handler = new $handlerClass($constructorParam);
/* third form -- does not work */
$handler = new (handlerFor($something))($constructorParam);
Expected result:
The third form ought to work just like the other two, so one doesn't
need to
create extra variable for single use.
Actual result:
--
PHP Parse error: syntax error, unexpected '(', expecting T_STRING or
T_VARIABLE
or '$'
--
Edit this bug report at http://bugs.php.net/bug.php?id=51808&edit=1
Req #50945 [Com]: [PATCH] func_get_args(offset=0)
Edit report at http://bugs.php.net/bug.php?id=50945&edit=1
ID: 50945
Comment by: + at ni-po dot com
Reported by:robert at binalan dot com
Summary:[PATCH] func_get_args(offset=0)
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: FreeBSD
PHP Version:5.2.12
Block user comment: N
New Comment:
@kwilson: Maybe this is a reason why he doesn't like to use array_shift:
You already used it wrong! To make it work you would need to write:
$data = func_get_args();
array_shift($data);
array_shift($data);
Better use array_slice:
$data = array_slice(func_get_args(), 2);
(This only works as of PHP 5.3, in PHP 5.2 you need to write: $data =
func_get_args(); $data = array_slice($data, 2);.)
I do support the introduction of this additional parameter. It is
annoying to always array_shift / array_slice some stuff from the
arguments ;)
Previous Comments:
[2010-03-06 12:50:28] ka...@php.net
The following patch has been added/updated:
Patch Name: func-get-args-with-offset
Revision: 1267876228
URL:
http://bugs.php.net/patch-display.php?bug=50945&patch=func-get-args-with-offset&revision=1267876228&display=1
[2010-02-16 21:30:46] kwilson at shuttlebox dot net
Why wouldn't you just use array_shift? The PHP folks don't seem to like
to implement features when there is already an approach to accomplish
the task in few steps:
function moduleNotify($module, $message/*, ...args*/)
{
$data = array_shift(array_shift(func_get_args()));
switch($module){
case 'Database':
list($host, $user, $pass, $base) = $data;
break;
case 'UserLogin':
list($user, $pass, $iris, $lang) = $data;
break;
}
[2010-02-06 07:53:23] robert at binalan dot com
Description:
function moduleNotify($module, $message/*, ...args*/)
{
switch($module){
case 'Database':
list($host, $user, $pass, $base) = func_get_args(2);
break;
case 'UserLogin':
list($user, $pass, $iris, $lang) = func_get_args(2);
break;
}
/*
feature request:
func_get_args(offset=0)
returns arguments in same zero based array from a given offset in the
argument list.
*/
--
Edit this bug report at http://bugs.php.net/bug.php?id=50945&edit=1
Req #50980 [Com]: lambda/anonymous functions do not have proper scope
Edit report at http://bugs.php.net/bug.php?id=50980&edit=1
ID: 50980
Comment by: + at ni-po dot com
Reported by:nate at frickenate dot com
Summary:lambda/anonymous functions do not have proper scope
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Linux
PHP Version:5.3.1
Block user comment: N
New Comment:
function () use (&$country)
will fix it (as the previous comment already says). This is in
concordance to the handling of arguments in normal functions and thus
mustn't be changed.
Previous Comments:
[2010-05-21 00:35:02] a at b dot c dot de
use() parameters are early binding - they use the variable's value at
the point where the lambda function is declared, rather than the point
where the lambda function is called (late binding).
If you want late binding then there is already syntax for that ('&') -
which works as expected to propagate assignments up to the calling
scope. To make it the default would be (a) contrary to the way
"ordinary" function parameters are passed, (b) require the addition of
new syntax to indicate that early binding is wanted, (c) deal with the
situation where a used variable doesn't exist at call time, (d) make it
hard to understand the difference between an ordinary function parameter
and a closure.
The problem with allowing variables in the outer scope to leak by
default into the lambda function is that a copy of the ENTIRE collection
returned by get_defined_vars() would need to be persisted for the
lifetime of the closure object (less any that are overridden by
call-time arguments) just in case any of them are needed.
'I imagine this has to do with the php5 "fake references" that are used
to pass objects around.'
The mechanism is the same as that used in Java and C#: the object
reference is passed by value. It's just that in PHP you also have the
option of passing the reference by reference as well (see the chapter in
the manual on "Objects and references", where it explains that what is
passed is an "object identifier" and not a PHP "reference").
[2010-02-09 22:53:17] nate at frickenate dot com
Description:
The way in which variables are passed to the inside of a lambda function
via the 'use (...)' syntax is broken. The entire concept of "scope" or
"closures" does not seem to apply in php whatsoever.
Variables within a lambda are supposed to be resolved/looked up in the
parent scope at runtime when the variable is actually accessed within
the lambda function's code. It seems that php just dumbly creates a copy
of the variable when it sees the definition of the lambda function with
the 'use (...)' clause. Changes to the variable in the parent scope
between the moment where the lambda is defined and the lambda function
is called are not propagated.
The worst part happens with objects. When passing in an object instance
to a lambda, any changes to the original object in the parent scope
after the lambda definition do affect the same object (problem 4 in
reproduce code), but replacing the object altogether does not (problem 3
in reproduce code). I imagine this has to do with the php5 "fake
references" that are used to pass objects around.
I get the feeling this is just a horrible limitation of the devs having
hacked a "best-possible" implementation of "lambdas" into a Zend
codebase that can't handle proper scope lookup. If this is the case, it
would be nice if the documentation could be updated to really nail home
the fact that there is no scoping going on at all, and that quite
literally all you get is a copy of the variable as it exists at the
moment the lambda is defined (except for the strangeness going on with
objects).
It's unfortunate that the "solution" for the time being is to *always*
pass in *every* variable as a reference, which results in expected
output. But this requires creating a local copy within the lambda for
every variable that one wants to modify without affecting the parent
scope. :'(
Reproduce code:
---
'UnitedStates');
$fn = function () use ($country) { echo $country->name . "\n"; };
$country = (object)array('name' => 'Canada');
$fn();
// problem 4: this outputs "Canada". if this outputs "Canada",
// then so should problem 2 above. otherwise this should be
// just as broken as problem 2 and be outputting "UnitedStates"
$country = (object)array('name' => 'UnitedStates');
$fn = function () use ($cou
Bug #52969 [Com]: This defined in static call from within another class
Edit report at http://bugs.php.net/bug.php?id=52969&edit=1
ID: 52969
Comment by: + at ni-po dot com
Reported by:ircmaxell at yahoo dot com
Summary:This defined in static call from within another
class
Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
New Comment:
@ircmaxell: No, you don't need to modify all your code and add that
line. Or at least you don't need to do so if you don't already have this
line in every method:
if (!isset($this)) throw new LogicException('Called non-static method
statically');
In PHP you can't rely on $this being set. But still you do, because an
unset $this is a real edge case.
But I still do think that this feature *is* a bug and shall be removed.
It is absolutely illogical that $this isn't instanceof self.
Previous Comments:
[2010-10-03 00:37:43] gnuffo1 at gmail dot com
Does it really mean you must put that line in every method? It's not
like you ever accidentally had a problem with it before is it?
[2010-10-02 21:05:25] ircmaxell at yahoo dot com
Close it if you wish, but I do honestly believe this is a major bug...
This means that you cannot trust that $this is an instance of the class
it's
used in. So does that mean that we must add:
($this instanceof self) or throw new Exception('called from another
class');
to all of our methods?
Remember, any sufficiently advanced bug is indistinguishable from a
feature (no
matter if it is documented or not). But don't be afraid to call it what
it
really is... Just because it's documented, doesn't mean it isn't a
bug...
Again, IMHO...
[2010-10-02 20:07:43] cataphr...@php.net
Closing as bogus. As you have pointed out, this is documented.
[2010-10-02 15:51:04] gnuffo1 at gmail dot com
It has been pointed out to me that this is actually documented:
http://us2.php.net/manual/en/language.oop5.basic.php
Under example 2 and specifically the lines:
$b = new B();
$b->bar();
[2010-10-02 15:33:50] php at rwasmus dot nl
Can reproduce across architectures & versions from 5.2.9 onward, IMHO
opinion, just an E_STRICT error in between is understating the scripters
design flaw. Some existing code may rely on it, so a real fix may hurt
some packages, but at the very least I'd increase the errors severity.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52969
--
Edit this bug report at http://bugs.php.net/bug.php?id=52969&edit=1
Req #52807 [Com]: magic __toArray() for objects
Edit report at http://bugs.php.net/bug.php?id=52807&edit=1
ID: 52807
Comment by: + at ni-po dot com
Reported by:jtegwen at gmail dot com
Summary:magic __toArray() for objects
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: n/a
PHP Version:Irrelevant
Block user comment: N
New Comment:
@aharvey: Couldn't the patch in the RFC you mentioned be modified to
support arrays, too? Or would the implementation for arrays be
completely different to the one for arrays?
Previous Comments:
[2010-09-12 04:06:35] ahar...@php.net
You are quite correct about request #52583. My apologies. I
remember skimming it when it came in, but obviously not very well. :)
To be honest, I think this is a better candidate for a thread on the
Internals mailing list or an RFC than a feature request here. I also
think this is extremely unlikely to make it in in any case,
particularly without a patch.
Nevertheless, I'll reopen this for now.
[2010-09-10 17:21:11] jtegwen at gmail dot com
I found that request when researching this one. I read that as casting
*to* an object not casting *from* an object.
Am I missing something?
[2010-09-10 04:58:39] ahar...@php.net
Probably better bundled under request #52583 -- the RFC linked to there
is specifically to deal with casting to scalar types, but the syntax
suggested in the feature request is general enough to deal with arrays.
[2010-09-09 22:33:53] jtegwen at gmail dot com
Description:
It would be nice to have an analogous method to __toString() for
arrays.. maybe __toArray() for customized array return.
Test script:
---
class myObject {
private $data1;
private $data2;
private $meta1;
public function __construct($data1, $data2) {
$this->data1 = $data1;
$this->data2 = $data2;
$this->meta1 = strlen($data1) + strlen($data2);
}
public function __toArray() {
return array('data1'=>$this->data1, 'data2'=>$this->data2);
}
}
$obj = new myObject('test', 'script');
var_dump($obj);
Expected result:
array('data1'=>'test', 'data2'=> 'script')
Actual result:
--
Not implemented
--
Edit this bug report at http://bugs.php.net/bug.php?id=52807&edit=1
Bug #52717 [Com]: Numeric property name can be set/get via variable but not static
Edit report at http://bugs.php.net/bug.php?id=52717&edit=1
ID: 52717
Comment by: + at ni-po dot com
Reported by:epicfailmail at tempinbox dot com
Summary:Numeric property name can be set/get via variable
but not static
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Windows 7
PHP Version:5.3.3
Block user comment: N
New Comment:
Use the complex variable syntax: $obj->{0} or $obj->{"0"} will work.
Previous Comments:
[2010-08-27 11:55:07] epicfailmail at tempinbox dot com
Description:
It is not possible to assign a numeric (integer or string) property name
directly but via a variable.
Test script:
---
$zero_int = "bar"; // works
$obj->$zero_str = "bar"; // works
$obj->0 = "bar"; // Parse error: syntax error, unexpected T_LNUMBER,
expecting T_STRING or T_VARIABLE or '{' or '$' in foo.php on line 9
$obj->"0" = "bar"; // Parse error: syntax error, unexpected
T_CONSTANT_ENCAPSED_STRING, expecting T_STRING or T_VARIABLE or '{' or
'$' in foo.php on line 10
print_r($obj->$zero_int); // works
print_r($obj->$zero_str); // works
print_r($obj->0); // Parse error: syntax error, unexpected T_LNUMBER,
expecting T_STRING or T_VARIABLE or '{' or '$' in foo.php on line 13
print_r($obj->"0"); // Parse error: syntax error, unexpected
T_CONSTANT_ENCAPSED_STRING, expecting T_STRING or T_VARIABLE or '{' or
'$' in foo.php on line 15
?>
Expected result:
I expected that both ways or neither of them would work.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52717&edit=1
Req #52583 [Com]: Improved casting and hinting, new magic method __cast()
Edit report at http://bugs.php.net/bug.php?id=52583&edit=1 ID: 52583 Comment by: + at ni-po dot com Reported by:martin dot leucht at gmail dot com Summary:Improved casting and hinting, new magic method __cast() Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N New Comment: @degeberg: Doesn't the RFC cover casting the other way round? I.e. Class -> Scalar Previous Comments: [2010-08-11 16:54:01] degeb...@php.net See: http://wiki.php.net/rfc/class_casting_to_scalar [2010-08-11 16:30:02] martin dot leucht at gmail dot com Description: Type casting in PHP is currently limited to the builtin types. It would be very useful (IMO) if one could cast a value/variable to a class. And also type hinting could be improved by casting instead of type checking only. I suggest to solve this by introducing a new magic method for classes, called "__cast()", that accepts the value to cast as parameter. I see two possible solutions for its functionality: (1) __cast() replaces the constructor method This will force the developer to move logics from the constructor into a separate function/method (which isn't even so bad) or to copy his code (which is indeed bad). If the function returns with the boolean value "false", the default error mechanism is started saying something like "cast to XYZ not allowed". (2) __cast() acts like a static constructor The code must return the casted result itself. That means one would implement some logics to transform the given value to the needed constructor parameters and create a new instance on his own. To handle an unsupported value the method would throw an exception or an error. The negative (or let's say curious) thing about this solution is, that this cast method could also return a value of a totally different type (see example). Test script: --- // see patch file Expected result: // working cast Actual result: -- // parse errors -- Edit this bug report at http://bugs.php.net/bug.php?id=52583&edit=1
Req #52626 [Com]: New magic method for procedural calls on object.
Edit report at http://bugs.php.net/bug.php?id=52626&edit=1
ID: 52626
Comment by: + at ni-po dot com
Reported by:jay at jay dot cz
Summary:New magic method for procedural calls on object.
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: *
PHP Version:Irrelevant
Block user comment: N
New Comment:
This problem would be fixed if PHP allowed casting to other scalar types
then strings and casting to arrays.
How it would work internally:
ksort($obj);
// =>
ksort((array) $obj);
// =>
ksort($obj->__cast('array'));
Bug #52807 deals with __toArray / cast to array.
Previous Comments:
[2010-08-18 15:49:04] email at robertdewilde dot nl
This comes close to the dynamic proxy class problem. It would really
make sense to fix this, as people want to use more OOP-style code.
Transparent implementing wrapperclasses would be a way to do this, if it
would be possible.
[2010-08-17 18:00:07] jay at jay dot cz
Description:
Classic style:
Object style:
ksort();
$oa->is_array(); //implemented in ObjArray
?>
But what if :
(SplTypes project is dead and I need object types.)
Now it is not possible to control, what functions are executed on
object.
If a language function is used on a object, php would
Variant 1) try to call object function of the same name,
Variant 2) call magic method __callOnObject if exists
Both variants can be implemented together.
Possible problem in variant 1)
Programmer would need to take care, to really implement exact same
structure of parameters, with all optional parameters, elze it would
throw errors on different arguments.
There could by a variant 1a) where, called function doesn't list all
arguments, but passes an array of arguments. But that would make object
calls too different from procedural.
Test script:
---
Variant 1)
class ObjArray extends ArrayIterator{
public function is_array( $var ){
return is_array( $this->storage );
}
public function is_object( $var ){
return is_object( $this->storage );
}
}
$obj = new ObjArray( Array( 1, 2 ) );
var_dump( is_array( $obj ) );
var_dump( is_object( $obj ) );
Variant 2)
class ObjArray extends ArrayIterator{
public function __callOnObject( $calledFunction, $params ){
switch $calledFunction {
case "is_array":
return $this->is_array( $params[0] );
break;
case "is_object":
return $this->is_object( $params[0] );
break;
default:
return $calledFunction( insert_params_irrelevant_how( $params )
);
}
}
public function is_array( $var ){
return is_array( $this->storage );
}
public function is_object( $var ){
return is_object( $this->storage );
}
}
$obj = new ObjArray( Array( 1, 2 ) );
var_dump( is_array( $obj ) );
var_dump( is_object( $obj ) );
Expected result:
Variant 1)
//$obj = new ObjArray( Array( 1, 2 ) );
//var_dump( is_array( $obj ) );
//should translate to var_dump( $obj->is_array( $obj ) );
bool(true)
//var_dump( is_object( $obj ) );
//should translate to var_dump( $obj->is_object( $obj ) );
bool(false)
Variant 2)
//$obj = new ObjArray( Array( 1, 2 ) );
//var_dump( is_array( $obj ) );
//should translate to var_dump( $obj->__callOnObject( "is_array", Array(
$obj ) ) );
//swith/case finds function is_array and calls $obj->is_array( $obj );
bool(true)
//var_dump( is_object( $obj ) );
//should translate to var_dump( $obj->__callOnObject( "is_object",
Array( $obj ) ) );
//swith/case finds function is_object and calls $obj->is_object( $obj
);
bool(false)
Actual result:
--
//$obj = new ObjArray( Array( 1, 2 ) );
//var_dump( is_array( $obj ) );
bool(false)
//var_dump( is_object( $obj ) );
bool(true)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52626&edit=1
Req #52528 [Com]: request for interface hashCode (Identifiable)
Edit report at http://bugs.php.net/bug.php?id=52528&edit=1
ID: 52528
Comment by: + at ni-po dot com
Reported by:giorgio dot liscio at email dot it
Summary:request for interface hashCode (Identifiable)
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: irr
PHP Version:Irrelevant
Block user comment: N
New Comment:
I see no reason for this to be implemented. Generate an spl_object_hash,
use (string) casting or implement your own ->toHash() method.
This is something you will want to do only ***very*** rarely. Thus it
shouldn't pollute the interface namespace.
Previous Comments:
[2010-08-03 23:20:42] jackohman at eugama dot com
would be really nice having the possibility to use different output
strings, one for readability, one for unique identify an object
class ArrayObject implements Identifiable
{
function hashCode(){return spl_object_hash($this);}
function __toString(){return json_encode($this);}
}
$obj = new ArrayObject();
$myarr[$obj] = (String)$obj;
very nice, i'm voting it
[2010-08-03 23:05:24] giorgio dot liscio at email dot it
Description:
i, i hope to see something like this in future php releases
interface Identifiable
{
public function /*string*/ hashCode();
}
class Test implements Identifiable
{
public function hashCode(){return spl_object_hash($this);}
}
method hashCode() should be called in these contexts:
$myarr[new Test()] = "test";
$myarrobj->{new Test()} = "test";
and manually inside:
function method(Identifiable $instance){};
the hash should be obtained by calling
$obj->hashCode() if it is Identifiable or
$obj->scalarValue() if it implements ScalarAccess
$obj->__toString() if it has method __toString
or, finally throw an error
what do you think about this?
thank you
--
Edit this bug report at http://bugs.php.net/bug.php?id=52528&edit=1
Bug #52441 [Com]: Arrays misbehaving with __set() and __get()
Edit report at http://bugs.php.net/bug.php?id=52441&edit=1
ID: 52441
Comment by: + at ni-po dot com
Reported by:bastard dot internets at gmail dot com
Summary:Arrays misbehaving with __set() and __get()
Status: Open
Type: Bug
Package:Class/Object related
Operating System: WIN
PHP Version:5.3.3 and 5.3.2
Block user comment: N
New Comment:
Could you elaborate your second point? I couldn't understand that one.
Concerning all the other ones: Our sixth point is the solution. This is
expected behavior. To modify an array property it must be returned by
reference. There already have been several bugs on this topic and yet
another one won't change anything ;)
Previous Comments:
[2010-07-26 01:50:34] bastard dot internets at gmail dot com
PHP Version: These bugs are found in 5.3.3 and 5.3.2. Unknown status in
5.2.
[2010-07-26 01:39:17] bastard dot internets at gmail dot com
Der, that last comment was meant to be "Amendment to Result #3". Ignore
that auto-linked reference to "bug #3"
[2010-07-26 01:36:21] bastard dot internets at gmail dot com
Amendment to bug #3: __set() is bypassed completely, and new arrays can
be freely created within objects if not already protected or private.
Only if directly setting the array itself (ie "$a->test_array =
array();") will __set() be called. But not when doing something like
"a$->test_array[] = 'asdf';"
[2010-07-26 01:19:24] bastard dot internets at gmail dot com
Description:
Mixing __set(), __get(), and protected/private/overloaded properties
that are arrays has unexpected, undocumented, and undesirable results.
A couple of bugs listed below. One bug is similar to bug 33941, but the
problem still persists and even more bugs have popped up.
Test script:
---
'test');
function __get($prop) {
if (!property_exists($this, $prop)) {
$this->$prop = null; // just to create it if it didn't
exist
}
return $this->$prop;
}
function __set($prop, $val) {
$this->$prop = $val;
}
}
$a = new A();
$a->test_array[] = 'asdf';
?>
Expected result:
New key/value "0=>'asdf'" assigned to protected class property array
'$test_array'. If the property didn't yet exist and overloading is
attempted, just create the new '$test_array' property as an array as
intended. Working with arrays in this manner should work exactly like
with any other variable type.
Actual result:
--
Depending on how the above test script is slightly tweaked, a few bugs
pop up. The focus here is on what happens with line "$a->test_array[] =
'asdf';"
1) If $test_array did *not* previously exist, "Notice: Indirect
modification of overloaded property A::$test_array has no effect in
...test.php on line 18". This *should've* worked fine.
2) If __set() was *not* declared, "Notice: Indirect modification of
overloaded property A::$test_array has no effect in ...test.php on line
18". This *should've* resulted in fatal "cannot access protected
property" error.
3) If $test_array did *not* previously exist and __get() was *not*
declared, it will work fine. __get() *should've* never factored in
here, and $test_array *should've* updated even if already declared
private/protected.
4) If __get() was *not* declared, "PHP Fatal error: Cannot access
protected property A::$test_array". __get() *should've* never factored
in here. If the '[]' compound operator is what's causing this, then
__get() should return a copy of the array with new or existing index if
provided to be processed through __set() as expected.
5) If $test_array was public, it will work fine, bypassing __get() and
__set() as intended. No bug here.
6) If __get() was declared to return a reference to the property (ie
function &__get($prop){}), it will work fine and bypass __set(). Not a
bug, but this workaround may cause other problems if expecting to
process updates through __set() or wanting just a copy of any other
property returned by __get().
--
Edit this bug report at http://bugs.php.net/bug.php?id=52441&edit=1
Req #52225 [Com]: __get() and __set() for static classes
Edit report at http://bugs.php.net/bug.php?id=52225&edit=1
ID: 52225
Comment by: + at ni-po dot com
Reported by:lucato at gmail dot com
Summary:__get() and __set() for static classes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:5.3.2
Block user comment: N
New Comment:
@henrik: This is about static property overloading, not about late
static binding ;)
Previous Comments:
[2010-07-08 14:45:42] henrik at bearwoods dot dk
In 5.3 it works if you change self:: to static:: like this
Test:
99, 'foo' => 101);
function __get($name) {
if (isset(static::$data[$name]))
return static::$data[$name];
return null;
}
}
class B extends A {
}
$object = new B();
print $object->foo;
Result
--
101
[2010-07-01 19:51:00] lucato at gmail dot com
Description:
Would it be possible to have magic setter/getter functions available on
static
context ?
The documentation says "Property overloading only works in object
context. These
magic methods will not be triggered in static context."
I would find it useful on a static context where I have a class A
extending
another class B, to access
Test script:
---
Example:
Class A {
static $data = array('bar' => 99, 'foo' => 101);
function __get($name) {
if (isset(self::$data[$name]))
return self::$data[$name];
return null;
}
}
Class B extends A {
}
echo B::$foo;
Expected result:
echo B::$foo;
In the example should return 101.
Actual result:
--
In the example it triggers a fatal error.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52225&edit=1
Bug #52969 [Com]: This defined in static call from within another class
Edit report at http://bugs.php.net/bug.php?id=52969&edit=1
ID: 52969
Comment by: + at ni-po dot com
Reported by:ircmaxell at yahoo dot com
Summary:This defined in static call from within another
class
Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
New Comment:
@jesse: That comment was completely unnecessary.
@all: I couldn't find any documentation on what a bogus bug is. Could
somebody tell (or link)? Thanks.
Previous Comments:
[2010-10-04 20:07:18] cataphr...@php.net
Yes, perhaps this feature ought to be removed, but the place to discuss
it is the internals mailing list.
In any case, it certainly wouldn't be removed from PHP 5.3, only trunk,
as it would be a breaking change.
[2010-10-04 19:43:23] jesse_7254 at yahoo dot com
A bogus bug is a bogus bug, no matter the opinion of StackOverflow
amateurs.
[2010-10-03 18:28:51] + at ni-po dot com
@ircmaxell: No, you don't need to modify all your code and add that
line. Or at least you don't need to do so if you don't already have this
line in every method:
if (!isset($this)) throw new LogicException('Called non-static method
statically');
In PHP you can't rely on $this being set. But still you do, because an
unset $this is a real edge case.
But I still do think that this feature *is* a bug and shall be removed.
It is absolutely illogical that $this isn't instanceof self.
[2010-10-03 00:37:43] gnuffo1 at gmail dot com
Does it really mean you must put that line in every method? It's not
like you ever accidentally had a problem with it before is it?
[2010-10-02 21:05:25] ircmaxell at yahoo dot com
Close it if you wish, but I do honestly believe this is a major bug...
This means that you cannot trust that $this is an instance of the class
it's
used in. So does that mean that we must add:
($this instanceof self) or throw new Exception('called from another
class');
to all of our methods?
Remember, any sufficiently advanced bug is indistinguishable from a
feature (no
matter if it is documented or not). But don't be afraid to call it what
it
really is... Just because it's documented, doesn't mean it isn't a
bug...
Again, IMHO...
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52969
--
Edit this bug report at http://bugs.php.net/bug.php?id=52969&edit=1
[PHP-BUG] Bug #53895 [NEW]: debug_zval_dump should be by ref
From: Operating system: PHP version: 5.3.5 Package: Unknown/Other Function Bug Type: Bug Bug description:debug_zval_dump should be by ref Description: debug_zval_dump should accept the variable by reference. Currently one can call the function either via debug_zval_dump($var) or debug_zval_dump(&$var). As the latter is as deprecated as it gets (i.e. parse-time deprecated) and is even removed in trunk, the function should be defined as accepting the variable by reference, because this is the usual use case. -- Edit bug report at http://bugs.php.net/bug.php?id=53895&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53895&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53895&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53895&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53895&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53895&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53895&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53895&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53895&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53895&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53895&r=support Expected behavior: http://bugs.php.net/fix.php?id=53895&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53895&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53895&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53895&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53895&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53895&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53895&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53895&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53895&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53895&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53895&r=mysqlcfg
Req #53895 [Wfx]: debug_zval_dump should be by ref
Edit report at http://bugs.php.net/bug.php?id=53895&edit=1 ID: 53895 User updated by: + at ni-po dot com Reported by: + at ni-po dot com Summary:debug_zval_dump should be by ref Status: Wont fix Type: Feature/Change Request Package:Variables related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: That would obviously be even better. I just wanted to note, that something must be changed about it. Previous Comments: [2011-02-01 13:49:28] cataphr...@php.net I disagree. Receiving the variable by reference would solve nothing, as it would force a separation on zvals with refcount > 1. What actually ought to be done is make debug_zval_dump work like xdebug's version and accepting a string. [2011-01-31 23:43:14] + at ni-po dot com Description: debug_zval_dump should accept the variable by reference. Currently one can call the function either via debug_zval_dump($var) or debug_zval_dump(&$var). As the latter is as deprecated as it gets (i.e. parse-time deprecated) and is even removed in trunk, the function should be defined as accepting the variable by reference, because this is the usual use case. -- Edit this bug report at http://bugs.php.net/bug.php?id=53895&edit=1
Req #53895 [Com]: debug_zval_dump should be by ref
Edit report at http://bugs.php.net/bug.php?id=53895&edit=1 ID: 53895 Comment by: + at ni-po dot com Reported by: + at ni-po dot com Summary:debug_zval_dump should be by ref Status: Wont fix Type: Feature/Change Request Package:Variables related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Hm, the problem seems to be more complicated when I thought. The only thing I can think of, that would allow arrays and objects, too, is to provide a function zval_is_ref that checks, whether the zval is_ref and then provide two function, zval_dump_by_ref and zval_dump_by_val. Imho this would cover all cases, but I assume that that's too many functions. Previous Comments: [2011-02-04 22:15:29] johan...@php.net The string version won't help for all cases, as you can't adress array elements or objects properly then. So there's no good way. [2011-02-01 15:13:07] + at ni-po dot com That would obviously be even better. I just wanted to note, that something must be changed about it. [2011-02-01 13:49:28] cataphr...@php.net I disagree. Receiving the variable by reference would solve nothing, as it would force a separation on zvals with refcount > 1. What actually ought to be done is make debug_zval_dump work like xdebug's version and accepting a string. -------- [2011-01-31 23:43:14] + at ni-po dot com Description: debug_zval_dump should accept the variable by reference. Currently one can call the function either via debug_zval_dump($var) or debug_zval_dump(&$var). As the latter is as deprecated as it gets (i.e. parse-time deprecated) and is even removed in trunk, the function should be defined as accepting the variable by reference, because this is the usual use case. -- Edit this bug report at http://bugs.php.net/bug.php?id=53895&edit=1
