Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63729
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
Sender: ekneuss@gmail.com
In-Reply-To: <50905FBD.1080208@sugarcrm.com>
References: <508A67E6.2000405@zerocue.com> <508A9AC9.50200@sugarcrm.com>
 <CAF+90c-VmscV0q=RAk7FE6+RLhjY8t9CRGY7QqpjB+3=b2XJTQ@mail.gmail.com>
 <508AF3E7.7020004@sugarcrm.com> <CAF+90c-RXwG7r=BW6_pDjRTaO3vJx6fGJhdwXV38GqHfBZNHVw@mail.gmail.com>
 <508B1EA2.8060203@sugarcrm.com> <508C249D.1000309@zerocue.com>
 <508C43ED.9000209@sugarcrm.com> <508C80C6.9000008@zerocue.com>
 <508CD916.1070509@sugarcrm.com> <508D5462.4070503@zerocue.com>
 <CAF+90c9xfOoZ13VN1xibXmUGCVfdGb3ymca=M5T86SSU9pY5zA@mail.gmail.com>
 <508EFB76.4080604@sugarcrm.com> <CAF+90c8MLs21T-HsDA8KH7js5BDz4fQceruTWncUzcw61Km6jg@mail.gmail.com>
 <50904C0C.8030207@sugarcrm.com> <CACQesk498M6ts1UYY22u0gkg8ackBXO+9DzkbhxEs9WP-GD-Aw@mail.gmail.com>
 <50905FBD.1080208@sugarcrm.com>
Date: Wed, 31 Oct 2012 12:21:37 +0100
Message-ID: <CACQesk64Wdc+KCDntDb_D2rwHbFtv0BQgyCT4FBqrbrxKUEj0w@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Clint Priest <cpriest@zerocue.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor
 Method Visibility / Callability
From: colder@php.net (Etienne Kneuss)

Hi,

On Wed, Oct 31, 2012 at 12:16 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> 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.

Well, LSP is typically not applied to program semantics, since this is
not a generally decidable problem. The only post-conditions that LSP
normally enforces is type based, i.e. the covariance of the return
type.

Instead, LSP simply states that, given B <: A, all objects of A can be
substituted by objects of B while preserving the validity of the
method calls on these objects, and the validity of their return
values. This is guaranteed here:

a get accessor will return a value of type any when performing
$a->foo, so does a property. LSP checks.
a set accessor takes a argument, so does $a->foo = "..". LSP checks.

My point is: all valid usages of accessors will also be valid when the
subclass overrides them using a normal property.

>
>> 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.

That's the same argument as before. Corresponding to LSP it only gives
very specific promises, that are simply type based and not the actual
strongest post-condition.

> 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.

Following your argument:

class A { public $v = 1; public foo() { $this->v = 2; } } class B
extends A {public foo() { $this->v = 4; }}

B should violate LSP, since the postcondition of B::foo() does not
imply postcondition of A::foo(). This is obviously not correct: this
code is fine.

Best,

>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227



-- 
Etienne Kneuss
http://www.colder.ch