Hi!
> handler, which is why it behaves differently from normal methods. In the
> time that I looked, I couldn't find where the access behavior for
> __construct and __destruct was controlled in the source code.
Access for functions is defined by zend_check_protected() and in
zend_std_get_method(), this code:
if (UNEXPECTED(!zend_check_protected(zend_get_function_root_class(fbc),
EG(scope)))) {
> In summary: should abstract protected constructors be inaccessible by
> siblings, as is true of __clone and __destruct? Should __construct, __clone
> and __destruct always be accessible in relatives, as is true of other
> methods? Depending on the answers, there could be a documentation issue, or
> bugs.
In general, function defined in base class should be accessible to all
siblings of that class. The rationale behind it is that if you define
function (even abstract) in your base class, you saying it will be
available to any instance (including extended ones) of this class. So
any descendant of this class can use it.
Now, I'm not sure why non-abstract ctors don't work this way - may be an
artifact of ctor being special function unlike all others. Needs to be
checked further in the code, I'll try to do it a bit later.
As for __clone, it may be a bug seeing that the same code in
zend_std_get_method() uses zend_get_function_root_class() but
zend_vm_def code does not. I don't see much reason why it is not there.
Same story with __destruct which is zend_objects_destroy_object() -
looks like zend_get_function_root_class() is missing there too. I'll
double check but from cursory look I see no reason why it's not there.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
