Re: Class Properties in Interfaces?

On Tue, Apr 29, 2008 at 9:22 PM, Robert Cummings <robert@interjinn.com> wrote: > > On Tue, 2008-04-29 at 19:01 -0600, Nathan Nobbe wrote: > > On Tue, Apr 29, 2008 at 6:14 PM, Richard Quadling < > rquadling@googlemail.com> > > wrote: > > > > > 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. > > > > > > > not only that, but the only recourse to add logic to access of previously > > declared public variables without changing the interface is to resort to > > magic methods. up front, using public member variables may be enticing, > > there are less instance methods and access is faster, sure. but when, > down > > the road, some logic is required around access, and the only recourse is > to > > employ a magic method, what would be slower then? the magic method doing > > runtime introspection on the class instance prior to invoking said logic, > or > > having a purpose built method(s) there in the first place? obviously the > > later; and that is just one more reason why getters and setters, coupled > > with hidden member variables, make sense, even in php. > > That should be a matter of choice for the developer. When you say "but > when, down the road, some logic...", all I see is you waving your hands > in the air and presuming that the logic will change. The logic may not > change, in which case why am I incurring the cost of getter/setter > methods. "If" the logic changes, I'll be happy to add getter and setter > methods at that time and punt the needed functionality into the magic > methods which will call the appropriate getter or setter method. You are > preparing for a future that may not come, I am willing to retroactively > handle that future "if" it arrives. Neither approach strikes me as being > more correct but rather they each presume an educated guess on the > likelihood of the property changing it's semantics down the road. the developer does have a choice. to use an interface, or an abstract class. data facilitates methods accomplishing what it is they purport. quite frankly, i have never written an interface with getters and / or setters anyway, nor do i see the need to. i would consider it silly. interfaces are typically used to say, any class that makes this happen will likely do it in a way differently than all the others. since, getters and setters are almost always implemented the exact same way i find these topics to be rather different. if there is in fact a standard way of doing things for any given interface, then to realize it, a common implementor class can be composed, and delegated to by classes that implement said interface in the 'standard' way. -nathan