On Wed, Apr 30, 2008 at 9:55 AM, Robert Cummings <[EMAIL PROTECTED]> wrote:
> > On Wed, 2008-04-30 at 09:39 -0600, Nathan Nobbe wrote: > > > > so really, all we would get is a group of member variables we know > > would be there... > > No, you know nothing about the existence of properties when using > getters and setters. Just because you have getColour() and setColour() > in no way implies you have $this->colour > right, thats exactly it, the client doesnt know anything about the data. it is being driven through a well-defined interface whereby the client has no control but to ask the provider to do something for it. > wow, that seems pretty pointless to me. It would seem it does. Wrapping all my properties in redundant > getter/setter methods often seems pointless to me and a whole slew of > other people. so put the public properties on classes that implement interfaces. as i said, getters and setters on an interfaces make little sense, since implementors are assumed to provide different implementations. > and in the case of the setter, the client doesnt know about the logic > > behind the call, so the fact is supplying 3.14 may not result in 3.14 > > actually getting set. > > You're presuming logic. I'm not. I just want to get/set the property > without invoking a function call. If properties didn't have their uses, > then you wouldn't be able to access them from the object. Since I'm not > forced to use a getter/setter method, then it follows that properties > were designed to be accessed and not necessarily wrapped in a method for > retrieval and setting. i understand your point. but just because the public access level exists, doesnt mean it was intended that member variables be assigned that level of access either. convention is to mark member variables protected or private, and drive access through a public well-defined *interface*. i have read at least a dozen books, ranging from various languages and topics and never have i heard of properties constituting part of the interface. indeed this would be an entirely new concept after generations that have arrived at the conclusion that an interface is a set of methods signatures. > > this is why setter methods are import, per my previous statements. > Important for some. You once again, with all your hand flapping, assume > we want some kind of operation on the data. If we do not, and this > happens a lot, then we're just wasting cycles... and order of magnitude > more cycles. > you are currently free to place public properties on any class or abstract class you wish. imho, that is entirely adequate. what i can say however, is that allowing such a feature forces designers and groups of developers to fall back on convention. that deviates from the entire purpose of interfaces. interfaces are about control; you must adhere to this contract. since php is loosely typed, the only way to maintain the 'intended' use of these properties would mean rigorous checking by developers of the code at design time. im not saying this is impossible, or something *some* people wouldnt be happy to do, in light of the performance gains. but the fact remains, the only thing that could maintain the integrity of the public properties would be rigorously maintained conventions. > i do not consider adding data 'after declaring properties' in > interfaces equivalent to supplying an implementation for the method, > because php is not strongly typed, therefore no class will ever be > able to control what sort of data is set on the properties. that is > the entire problem with your proposition. Ummm, this functionality already exists. Your argument neglects to > consider that objects already exist where the properties can be directly > accessed and set. Your argument assumes a need to "manage" the data > being assigned. Your argument assumes the data wasn't already "managed" > by the assigner of the data. You assume a lot, and yet we all know in > practice there are many, many, MANY implementations of classes where the > properties are directly exposed. This may not be something YOU like, but > it is what many others like. Some people still care about efficient code > versus the flexibility of meeting a demand that may never arise. > this much you are right about. > > i have to work today, and im sure people are getting sick of my > > bickering, but truthfully, i would like to know why interfaces were > > added to php in the first place? where, if any place, did they take > > inspiration from, java, c++, neither ? i only ask because im dying to > > know and we're on the topic.. > > Create a new thread. You rider question isn't relevant to this thread. > fine. -nathan
