Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63411
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: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local>
Date: Mon, 15 Oct 2012 15:29:25 +0200
Message-ID: <CACQesk5MLCqhdKr9j30WmL6ySTeMpVVEs9q2UfOjYbA+4bp_Yw@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: "Nikita Popov (nikita.ppv@gmail.com)" <nikita.ppv@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
From: colder@php.net (Etienne Kneuss)

Hi,

>
> Interfaces are a tough one, I would just like to point out that, again ac=
cessors are fundamentally different than properties, they just happen to sh=
are the same "use" syntax but act entirely differently.  The difficulty wit=
h allowing an interface to enforce a property is that the implementing clas=
s doesn't know when that property has changed or been accessed, whereas wit=
h an accessor they are required to write code that responds to the use of t=
he property.
>
>
>
> I hate to keep pointing to C# but (IMHO) it's a leader in terms of functi=
onality for a language and PHP is so similar to the C* family of languages =
it would follow suit that we should continue that direction as its probably=
 one of the reasons it has grown in popularity so much (any C* programmer c=
an write PHP with minimal new understanding, and new programmers are expose=
d to an easy language which mimics some of the best other languages out the=
re); and thus, C# specifically permits accessors within an interface.
>
>
>
> I have no personal stake in this desire to keep them as I do not use inte=
rfaces (very often) but from a purist point of view on the concept of inter=
faces I wanted to finish this up with an example of an interface that could=
 exemplify why they should be allowed:
>
>
>
> interface iVehicle {
>
>                 public $TireCount { get; }
>
>                 public $EngineType { get; }
>
>                 public $IsFunctional { get; }
>
>                 public $Speed { get; }
>
>
>
>                 public $OutputLocale { get; set; }  /* Do we output MPH o=
r KPH, for example)
>
>
>
>                 public function Drive();
>
> }

Interfaces are defined to specify how a an object implementing a
certain interfaces can be used. The clear indication of this is that
only public methods are allowed in interfaces.

For instance, an interface A with a get accessor on the property "foo"
will only tell you that, given that $obj implements A, you will be
able to read $obj->foo.

In fact, the following code

interface A {
   public $a { get; set }
}

class B implements A {
   public $a;
}

should be valid. In terms of capabilities, the class B implements all
the requirements imposed by the interface A. (The same goes if A was a
class,  BTW)

Is that the case in your current patch? (I couldn't find information
in your RFC nor in the tests on github)
If it is the case, I'm fine with having accessors and not plain
properties in interfaces.

Best,


>
> -Clint



--=20
Etienne Kneuss