Re: 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