* I'm moving this into its own mail thread because talking about 5 different topics under the same chain is ridiculous (has anyone suggested forums instead of email??)
> So here comes my round of feedback on the current proposal. > > But before getting to that: I have collected a bit of data how getter and > setter are currently used in Symfony and ZF: > https://gist.github.com/3884203 Mainly so I get a better overview of the > situation, but might be of interest for other people involved > in this discussion too. > > So, my points on the proposal, in no particular order: > 2. Interfaces > ------------------ > > I already mentioned this before, but I'll reiterate it here again: > Currently properties and properties with accessors are handled different with > regards to interfaces. In particular, if you have an > interface such as follows: > > interface Extension { > public $name { get; } > // more stuff > } > > then the following is not a valid implementation of the interface: > > class FooExtension implements Extension { > public $name = 'foo'; > // more stuff > } > > This does not make sense to me: $foo->name is a gettable property, as such it > satisfies the interface. I don't see a reason why we > would need a hard distinction between properties and properties with > accessors here. > > The converse is also true: An interface currently can not define a "plain" > property: > > interface Foo { > public $foo; > } > > I would expect this interface definition to be the same as "public $foo { > get; set; }". But I'm not sure on this point, as one could argue > that it's just a redundant way to say the same thing. Etienne Kneuss Wrote: > I have to agree here. > > Interfaces are means to describe the capabilities of an object from the > outside. And from the outside, properties defined through accessors are used > like properties, not methods. > > It would IMHO be better not to support accessors in interfaces until > properties are also (if ever) supported. Jazzer Dane Wrote: > In terms of interfaces, Clint's reason for allowing accessors in interfaces > is moderately sensible: to remain cohesive with the already allowed __get and > __set magic methods that are usable in interfaces. That's the underlying > issue. If we want to require an object to be able to be converted to a > string, we can sensibly put __toString in the interface. But what does > forcefully implementing __get or __set do for the object? What does it tell > us about how we're able to use it? It relates to properties in arguably such > a manner that we(i.e. accessing the object's API) nor the interface should > care about. But that's an argument for another day. > > So what do we do right now, then? If we allow it in interfaces, my main worry > is that people will put the accessor in an interface just because they can't > put a property, and they'd use the accessor as a normal, basic property. 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(); } Clearly much more could be added to that interface, it probably isn't even a good interface, but it illustrates my point I think. These accessors answer questions about a vehicle and provide one way to make it move. The two biggest problems with allowing properties with interfaces is symmetrical only access and non-observability, neither of which accessors have a problem with. The alternative interface that would have to be written for the above interface without allowing accessors is the old get/set function calls (which I think just about everyone hates, no?): interface iVehicle { public function getTireCount(); public function getEngineType(); public function getIsFunctional(); public function getSpeed(); public function getOutputLocale(); public function setOutputLocale(); public function Drive(); } I think that accessors should be allowed with interfaces because an interface really is a specification on how to communicate and while accessors do pass messages, properties do not. -Clint
