Re: Property Accessors v1.2 : Interfaces

Hi, On Mon, Oct 15, 2012 at 3:55 PM, Clint Priest <cpriest@zerocue.com> wrote: > I would bet, that at present, what you've put down is not allowed because I purposely > leveraged functions in this regard because all of the restrictions put in place against functions > would apply to accessors (because they are functions). I would have to test it to be certain > though. > > Because of Nikita's desire to not have underlying __getXX() functions exposed in any way > this may have to change. I had spent several hours actually divorcing the created function from the > Functions HashTable and later realized I could simply enforce their non-existence at call time, this > has turned somewhat problematic for static accessors though. > > Also, your "should be valid" statement implies that you feel properties and accessors > are the same and they are not, internally. When a class attempts to implement an interface a > "function check" is done and since there is no __getXX() function defined it would fail to > implementation check against an interface. > > I cannot stress enough that properties != accessors in any way except the syntax in which they > are used ($o->xyz) or ($o->xyz = 1), that is their *only* similarity. I not saying accessors are properties. I'm saying that interfaces define usage contracts. And from the point of view of usage contacts: interface A { public $a {get; set; } } is entirely fulfilled by the class: class B extends A { public $a; } You can see a public property as an underlying private property with all usual public accessors defined. From the point of view of the user both should be interchangeable transparently. > >> -----Original Message----- >> From: ekneuss@gmail.com [mailto:ekneuss@gmail.com] On Behalf Of Etienne Kneuss >> Sent: Monday, October 15, 2012 8:29 AM >> To: Clint Priest >> Cc: Nikita Popov (nikita.ppv@gmail.com); internals@lists.php.net >> Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces >> >> Hi, >> >> > >> > Interfaces are a tough one, I would just like to point out that, again accessors are >> > fundamentally different than properties, they >> just happen to share 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 functionality >> > 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 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 interfaces (very >> > often) but from a purist point of view on the >> concept of interfaces 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 or 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 >> >> >> >> -- >> Etienne Kneuss -- Etienne Kneuss http://www.colder.ch