Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37322
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.158 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=j2ZdC/E14Z+GmkQn/mcrALmgzRW4P4Di7eKC1UNTSSMShTl7B0NqL491Gy2LZpYIpo/G19+XoWn7sZ7W5A7vZ3F3sfDJ71O1y4cjEyRa4gMwor+Up2G6CdInLHg4YPurOwZ3cND/Y+iCAf94gI0WgygfYS1BvdL7MG3B7VFtVpY=
Message-ID: <7dd2dc0b0804292051o4fd5e77eu6f8faecad93c378a@mail.gmail.com>
Date: Tue, 29 Apr 2008 23:51:41 -0400
To: "Robert Cummings" <robert@interjinn.com>
Cc: RQuadling@googlemail.com, 
	"John Carter -X (johncart - PolicyApp Ltd at Cisco)" <johncart@cisco.com>, 
	internals@lists.php.net
In-Reply-To: <1209518549.7057.313.camel@blobule>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_16090_7961030.1209527501760"
References: <48169695.9040803@omegavortex.net>
	 <BADE85FDE9053E4AAEC411E40C77C2911A6693@xmb-ams-33e.emea.cisco.com>
	 <fv6sgn$676$1@ger.gmane.org>
	 <27A086AB-E111-49C1-ABBD-28FB6E1677BD@procata.com>
	 <48175A65.4070301@zend.com>
	 <BADE85FDE9053E4AAEC411E40C77C2911A697B@xmb-ams-33e.emea.cisco.com>
	 <1209512914.7057.296.camel@blobule>
	 <10845a340804291714g7eb10362m17af4abecbadf0e4@mail.gmail.com>
	 <7dd2dc0b0804291801m627a7c31h8dd796d7fa1d1257@mail.gmail.com>
	 <1209518549.7057.313.camel@blobule>
Subject: Re: [PHP-DEV] Class Properties in Interfaces?
From: quickshiftin@gmail.com ("Nathan Nobbe")

------=_Part_16090_7961030.1209527501760
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_16090_7961030.1209527501760--