Edit report at https://bugs.php.net/bug.php?id=47476&edit=1

 ID:          47476
 Updated by:  php-bugs@lists.php.net
 Reported by: nullhility at gmail dot com
 Summary:     Overloading does not work internally
-Status:      Feedback
+Status:      No Feedback
 Type:        Feature/Change Request
 Package:     Class/Object related
 PHP Version: 5.2.8

 New Comment:

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


Previous Comments:
------------------------------------------------------------------------
[2011-04-08 20:39:58] j...@php.net

Your pastebin stuff isn't available anymore, please put the examples straight 
into this report.

------------------------------------------------------------------------
[2009-02-22 19:34:05] nullhility at gmail dot com

I re-evaluated the problem itself and found that the magic methods for 
overloading aren't called automatically from "inside" the object if the member 
has been initialized in the class regardless of access.

I've made two examples of this "internal" call to overloading behavior, the 
first works, the second does not but the average user would expect it to.

calls the magic methods directly:
    http://nullhility.pastebin.com/m5f55a558

expects the magic methods to be called directly:
    http://nullhility.pastebin.com/m654d81ea

------------------------------------------------------------------------
[2009-02-22 17:30:33] nullhility at gmail dot com

Description:
------------
I was attempting to overload some object members when I came to the realization 
that members defined as unaccessible from inside an object are ones that have 
not been initialized at all. I was attempting to call a defined but not yet set 
private member from a method in the class, I expected the __get definition to 
execute and hopefully do a late member cast but PHP saw it as accessible, this 
caused a problem because the method was calling a NULL value.

The way I see it is that a NULL, aside from still being a value itself, is 
pretty inaccessible as an actual value. My main concern is that calling an 
undefined member returns NULL but is also defined as inaccessible, yet calling 
a defined (but unset/not set) private/protected from within the object, though 
returning null, is accessible.

In the end I know it's about scope and correctness, but is this issue up for 
change?

Reproduce code:
---------------
http://nullhility.pastebin.com/m486cded3

Expected result:
----------------
Hello World!
Hello Universe!
Hello Everyone!

Actual result:
--------------
Hello World!

Hello Everyone!


------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=47476&edit=1

Reply via email to