Hi, On Mon, Oct 15, 2012 at 3:55 PM, Clint Priest <cpri...@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: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of Etienne >> Kneuss >> Sent: Monday, October 15, 2012 8:29 AM >> To: Clint Priest >> Cc: Nikita Popov (nikita....@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php