Re: Class Properties in Interfaces?

2008/4/30 Robert Cummings <robert@interjinn.com>: > > On Tue, 2008-04-29 at 20:04 +0200, John Carter -X (johncart - PolicyApp > > Ltd at Cisco) wrote: > > I think there's been two responses to this query: > > > > 1. We can't have properties in interfaces because interfaces don't have > > properties. I would say this is tautological and doesn't add anything. > > > > 2. Why would you need to? Getters and setters work. > > > > So I suppose to answer my question for myself, there's no real technical > > reason for not having properties in interfaces, but getters and setters > > work just fine and no-one (including me) really misses them. > > I have to agree. Enforcing existence of a property is just as much part > of an interface as enforcing the existence of a method. Why go down the > clutzy getter and setter method route when properties were meant to be > accessed. Why should code be made slower? Methods are at least an order > of magnitude slower than direct property access. > > Cheers, > Rob. > -- > http://www.interjinn.com > Application and Templating Framework for PHP There are some advantages. 1 - Read only / write only properties can be created more obviously, rather than having the logic spread thoughout the __magic_functions. 2 - Automatic document tools get a real benefit from having a defined mechanism to work from. Using a simple shape class, it is a toss up between $shape->getArea() vs $shape->area If PHP supported setters/getters in this way, then the interface for a shape would have a fCalcArea member function requirement. You may want to have the area updated upon the change of any of the dimensions. Ideally the interface should also have a read only property of area, but the support of properties in an interface is disputed here. In this limited example, it would seem useful. Richard. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"