Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:37357 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74228 invoked from network); 30 Apr 2008 15:55:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Apr 2008 15:55:45 -0000 Authentication-Results: pb1.pair.com header.from=robert@interjinn.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=robert@interjinn.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain interjinn.com from 66.11.173.122 cause and error) X-PHP-List-Original-Sender: robert@interjinn.com X-Host-Fingerprint: 66.11.173.122 unknown Received: from [66.11.173.122] ([66.11.173.122:59145] helo=interjinn.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 00/63-55591-08698184 for ; Wed, 30 Apr 2008 11:55:45 -0400 Received: from [192.168.1.3] (blobule.suds [192.168.1.3]) by interjinn.com (Postfix) with ESMTP id 01D4011FB6D; Wed, 30 Apr 2008 11:55:40 -0400 (EDT) To: Nathan Nobbe Cc: RQuadling@googlemail.com, "John Carter -X (johncart - PolicyApp Ltd at Cisco)" , internals@lists.php.net In-Reply-To: <7dd2dc0b0804300839t49c5788dsf3e536d4eafb844f@mail.gmail.com> References: <48169695.9040803@omegavortex.net> <10845a340804291714g7eb10362m17af4abecbadf0e4@mail.gmail.com> <7dd2dc0b0804291801m627a7c31h8dd796d7fa1d1257@mail.gmail.com> <1209518549.7057.313.camel@blobule> <7dd2dc0b0804292051o4fd5e77eu6f8faecad93c378a@mail.gmail.com> <1209528338.7057.349.camel@blobule> <7dd2dc0b0804292127p484d8c7g9cf852f0a79a8dc6@mail.gmail.com> <1209532046.7057.368.camel@blobule> <7dd2dc0b0804292222h29c8845k456f6546cbdbece6@mail.gmail.com> <1209535288.7057.406.camel@blobule> <7dd2dc0b0804300839t49c5788dsf3e536d4eafb844f@mail.gmail.com> Content-Type: text/plain Organization: InterJinn Date: Wed, 30 Apr 2008 11:55:41 -0400 Message-ID: <1209570941.6963.70.camel@blobule> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Class Properties in Interfaces? From: robert@interjinn.com (Robert Cummings) 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 > 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. > 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. > 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. > 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. > 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. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP