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. > -----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
