Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63409
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.41 as permitted sender)
To: "Nikita Popov (nikita.ppv@gmail.com)" <nikita.ppv@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
Thread-Index: Ac2qzmY/IrEbFiHmS8CRVRSeKx1+9g==
Date: Mon, 15 Oct 2012 12:34:49 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_9570D903A3BECE4092E924C2985CE485612B6466MBX202domainloc_"
MIME-Version: 1.0
Subject: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
From: cpriest@zerocue.com (Clint Priest)

--_000_9570D903A3BECE4092E924C2985CE485612B6466MBX202domainloc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

* I'm moving this into its own mail thread because talking about 5 differen=
t topics under the same chain is ridiculous (has anyone suggested forums in=
stead of email??)



> So here comes my round of feedback on the current proposal.

>

> But before getting to that: I have collected a bit of data how getter and=
 setter are currently used in Symfony and ZF:

> https://gist.github.com/3884203 Mainly so I get a better overview of the =
situation, but might be of interest for other people involved

> in this discussion too.

>

> So, my points on the proposal, in no particular order:

> 2. Interfaces

> ------------------

>

> I already mentioned this before, but I'll reiterate it here again:

> Currently properties and properties with accessors are handled different =
with regards to interfaces. In particular, if you have an

> interface such as follows:

>

>     interface Extension {

>         public $name { get; }

>         // more stuff

>     }

>

> then the following is not a valid implementation of the interface:

>

>     class FooExtension implements Extension {

>         public $name =3D 'foo';

>         // more stuff

>     }

>

> This does not make sense to me: $foo->name is a gettable property, as suc=
h it satisfies the interface. I don't see a reason why we

> would need a hard distinction between properties and properties with acce=
ssors here.

>

> The converse is also true: An interface currently can not define a "plain=
" property:

>

>     interface Foo {

>         public $foo;

>     }

>

> I would expect this interface definition to be the same as "public $foo {=
 get; set; }". But I'm not sure on this point, as one could argue

> that it's just a redundant way to say the same thing.



Etienne Kneuss Wrote:

> I have to agree here.

>

> Interfaces are means to describe the capabilities of an object from the o=
utside. And from the outside, properties defined through accessors are used=
 like properties, not methods.

>

> It would IMHO be better not to support accessors in interfaces until prop=
erties are also (if ever) supported.



Jazzer Dane Wrote:

> In terms of interfaces, Clint's reason for allowing accessors in interfac=
es is moderately sensible: to remain cohesive with the already allowed __ge=
t and __set magic methods that are usable in interfaces. That's the underly=
ing issue. If we want to require an object to be able to be converted to a =
string, we can sensibly put __toString in the interface. But what does forc=
efully implementing __get or __set do for the object? What does it tell us =
about how we're able to use it? It relates to properties in arguably such a=
 manner that we(i.e. accessing the object's API) nor the interface should c=
are about. But that's an argument for another day.

>

> So what do we do right now, then? If we allow it in interfaces, my main w=
orry is that people will put the accessor in an interface just because they=
 can't put a property, and they'd use the accessor as a normal, basic prope=
rty.



Interfaces are a tough one, I would just like to point out that, again acce=
ssors are fundamentally different than properties, they just happen to shar=
e the same "use" syntax but act entirely differently.  The difficulty with =
allowing an interface to enforce a property is that the implementing class =
doesn't know when that property has changed or been accessed, whereas with =
an accessor they are required to write code that responds to the use of the=
 property.



I hate to keep pointing to C# but (IMHO) it's a leader in terms of function=
ality 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 o=
ne of the reasons it has grown in popularity so much (any C* programmer can=
 write PHP with minimal new understanding, and new programmers are exposed =
to an easy language which mimics some of the best other languages out there=
); 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 interf=
aces (very often) but from a purist point of view on the concept of interfa=
ces I wanted to finish this up with an example of an interface that could e=
xemplify 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 or =
KPH, for example)



                public function Drive();

}



Clearly much more could be added to that interface, it probably isn't even =
a good interface, but it illustrates my point I think.  These accessors ans=
wer questions about a vehicle and provide one way to make it move.



The two biggest problems with allowing properties with interfaces is symmet=
rical only access and non-observability, neither of which accessors have a =
problem with.  The alternative interface that would have to be written for =
the above interface without allowing accessors is the old get/set function =
calls (which I think just about everyone hates, no?):



interface iVehicle {

                public function getTireCount();

                public function getEngineType();

                public function getIsFunctional();

                public function getSpeed();



                public function getOutputLocale();

                public function setOutputLocale();



                public function Drive();

}



I think that accessors should be allowed with interfaces because an interfa=
ce really is a specification on how to communicate and while accessors do p=
ass messages, properties do not.



-Clint

--_000_9570D903A3BECE4092E924C2985CE485612B6466MBX202domainloc_--