Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63401 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48291 invoked from network); 14 Oct 2012 09:39:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Oct 2012 09:39:57 -0000 Authentication-Results: pb1.pair.com header.from=cpriest@zerocue.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cpriest@zerocue.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.40 as permitted sender) X-PHP-List-Original-Sender: cpriest@zerocue.com X-Host-Fingerprint: 74.115.204.40 relay-hub204.domainlocalhost.com Received: from [74.115.204.40] ([74.115.204.40:42028] helo=relay-hub204.domainlocalhost.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/74-11197-A688A705 for ; Sun, 14 Oct 2012 05:39:55 -0400 Received: from MBX202.domain.local ([169.254.169.44]) by HUB204.domain.local ([192.168.68.48]) with mapi id 14.02.0283.003; Sun, 14 Oct 2012 05:39:02 -0400 To: Amaury Bouchard CC: Nikita Popov , Benjamin Eberlei , "internals@lists.php.net" Thread-Topic: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 Thread-Index: Ac2oOZ3+vAOzWRcnRpOb6a/hOVK5+ABAY8yAAALpNQAAAUOoAAAEr8EwAACGpYAAB+4qMAAKcpQAAAQ9rMkAEtmfAAAFwtfA Date: Sun, 14 Oct 2012 09:39:01 +0000 Message-ID: <9570D903A3BECE4092E924C2985CE485612B5F0A@MBX202.domain.local> References: <9570D903A3BECE4092E924C2985CE485612B53E4@MBX202.domain.local> <9570D903A3BECE4092E924C2985CE485612B59F6@MBX202.domain.local> <9570D903A3BECE4092E924C2985CE485612B5A54@MBX202.domain.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.64.27] Content-Type: multipart/alternative; boundary="_000_9570D903A3BECE4092E924C2985CE485612B5F0AMBX202domainloc_" MIME-Version: 1.0 Subject: RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 From: cpriest@zerocue.com (Clint Priest) --_000_9570D903A3BECE4092E924C2985CE485612B5F0AMBX202domainloc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Amaury, Good points all around, but one last thing to point out, interfaces only de= clare what *must* be supported by an implementer, properties have no "imple= mentation", they just are. Whereas an accessor *has* an implementation. S= o when you see that an interface has an accessor, you can rely on the fact = that anyone who implements that interface *must* implement an accessor of t= he given name. From: amaury.bouchard@gmail.com [mailto:amaury.bouchard@gmail.com] On Behal= f Of Amaury Bouchard Sent: Sunday, October 14, 2012 3:23 AM To: Clint Priest Cc: Nikita Popov; Benjamin Eberlei; internals@lists.php.net Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 You are right, we can define __get() in an interface. So, in the end I will= shut my mouth. But still, it's not logical. An interface is a contract which defines the c= apacities of an object. If an interface defines the entry point swim(), we = know that an object which implements this interface is able to swim. The go= al is to define what is callable in an implementation (the basics of duck t= yping: if it can swim() and fly(), it's a flying fish). In PHP, it was decided that interfaces may not include member variables. I = guess it's a philosophical choice; you give orders to an object, knowing wh= at it can do (thanks to the interface). And orders are given by calling met= hods, not by setting properties. As I understand your explanation, you think it's normal to be able to defin= e accessors in an interface, because it means there is some code behind. Bu= t from my point of view, the implementation (in the PHP interpreter) is not= relevant; it's a design choice first. Take a look at this code: interface Fooable { public $aaa { get; set; } } class Fooer implements Fooable { public $aaa { get { /* wathever ... */ } set { /* ... you want */ } } } class Bar { public function do() { $foo =3D new Fooer(); $foo->aaa =3D 3; } } The Bar object doesn't care if $aaa is an attribute or an accessor. It is u= sed the same way. So, if we agree that this code is correct, I understand that something like= "$foo->aaa" is a valid entry point to communicate with an object through a= n interface. TIt means that an API is not only defined by methods. You can argue that an accessor is different from a property, but again, onl= y Fooer knows that, Bar shouldn't have to deal with that. Then, for me there is two logical choices: - Forbid accessors in interfaces, as properties are already forbidden. - Allow accessors in interfaces =3D> allow properties too. But it is a comp= lete redefinition of interfaces in PHP. I saw the link you gave to me. Well, as I said before, there is a lot of go= od ideas in C#, but I think PHP is an opinionated language and we can do ou= r own choices (see how namespaces work in a very different way from C++ nam= espaces, for example). As you point out, __get() implies the choice has already be done. So I shut= up now :-) 2012/10/14 Clint Priest > -Clint On Oct 13, 2012, at 4:21 PM, "Amaury Bouchard" > wrote: 2012/10/13 Clint Priest > Interfaces are used to define what methods must be present, properties are = not allowed. Yes, so no one should be correct, right? I mean, yes the first declaration implies some code; but for the interface,= it's still a property definition. You're mixing concepts here, it's an accessor definition, not a property de= finition. property !=3D accessor, an accessor just happens to look and act= like a property (which is the point of accessors). Interfaces define methods, not properties. Fine. But is an accessor (as defined in the RFC) a method? Or should we consider = that an accessor definition is valid inside an interface? I would say no, b= ecause it will be used as a property: outside of the object that implements= the accessor, nobody know if it's an attribute or an accessor function. It's the whole point of the RFC (apart from the asymetric visibility, but y= ou know my point of view). So, for me, this code should be incorrect: interface Fooable { public $abc { get; set; } } Because if an object implements the interface: class Fooer implements Fooable { public $abc { get { /* what you want */ } set { /* what you want too */ } } } How this code will be used? Like that: $foo =3D new Fooer(); $foo->abc =3D 3; print($foo->abc); Everybody will agree with me that $abc is used like a property, not as a me= thod. So the language should enforce that. There is a real issue here; this is not a fad from me. An accessor is a method and an interface which defines an accessor is indic= ating that the accessor must be implemented by any using the interface. See: http://msdn.microsoft.com/en-US/library/64syzecx(v=3Dvs.80).aspx Also, "used like a property" does not mean it is a property, it is a method= call with the syntax of accessing a property, it is still a method call. I believe __get() may be declared in an interface and if so, then accessors= should be as well. --_000_9570D903A3BECE4092E924C2985CE485612B5F0AMBX202domainloc_--