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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
