Hi!
> #5: From what I understand, an extending class can not override an
> accessor with a non-accessor.
This should be in the RFC then - along with what exactly happens. Note
that this will represent a sort of BC break in terms that you could have
two properties $a before, but if you change implementation of $a in base
class from plain old property to accessor property, the child class
would break. Which is not good, since compatible changes in parent class
should not break child classes - and which will also impede adoption of
this feature, since you can not guarantee no child class does it.
> #11: If you set an accessor's get or set to /final private/, you are not
> able to extend and it are only able to invoke it from the current class.
> If you don't invoke it, then it is virtually read or write only.
I get this, but what do you write as a method body if you want to just
disallow it? Do you write just {}? Then it's not good for get() since
get() is supposed to return a value, and also not good for set() since
base class still can call private methods, and we want set() to be not
available for everybody.
--
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
