Re: [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! >> I'm not sure why you are expecting this, and also this is probably an >> LSP violation, since such override would change semantics of the value >> that A clients expect. It may be possible to implement, technically, but >> I'm not sure it's the right thing to do. > > Why would it be not expected and/or a violation of LSP? Accessors > impose stricly more restrictions than properties. This code is fine. You assume accessors are restrictions, but they don't have to be. Consider: public $foo { get() { return $this->foo;} set($v) { $this->foo_copy = $this->foo = $v; } } You have a postcondition on set() that $this->foo_copy will be the same as $this->foo. Override with "public $foo" removes that postcondition. But proper inheritance should only strengthen the postconditions, not drop them. > Just like it is fine in theory to have interface A { public $foo { > get(); set($v); } } class B implements A { public $foo; } That's different. In this case, you say "I will have some property $foo", without promising anything about it. But specific code can actually make some promises about $foo, and you can violate these promises by overriding it with public $foo. Interface does not impose any conditions except that $foo exist and is gettable/settable. Specific getters/setters can impose much more involved conditions, which "public $foo" may not be able to satisfy. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227