Re: Property Accessors v1.2

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