Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50871
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type:content-transfer-encoding;
        b=f04A7arlOfx5C/e++0Q5pZuKpiY4Ukemuxhi4RUhqio0PjeS4eh2SBiXB7PBV5Ngv0
         FSvN9bFtOtkWXD7BhB5JZc77E6Yl5kiru19F28HWjPCx61EetjlQY8Cf+55eeWvUl+nK
         1rFp5oTvqZ9p8u8koeYY77+S64UoeboEcrwAk=
MIME-Version: 1.0
Reply-To: RQuadling@googlemail.com
In-Reply-To: <e423a80669e2045f17b5febc4bb7edd2.squirrel@webmail.basnetworks.net>
References: <ae7aa0536c47a2ac725222d49918183f.squirrel@webmail.basnetworks.net>
 <003601cb8fd0$f6494e80$e2dbeb80$@com> <4CF3B855.5010406@sugarcrm.com>
 <003401cb8fee$1be39840$53aac8c0$@com> <2450924ae03481f5b1382a7f00e5743d.squirrel@webmail.basnetworks.net>
 <4CF50245.5020807@sugarcrm.com> <ed0a2b6089e32bc3def3c14a1f510246.squirrel@webmail.basnetworks.net>
 <4CF5118B.2030300@sugarcrm.com> <1faa4c3db62771335db714507ac2adfa.squirrel@webmail.basnetworks.net>
 <4CF613EB.40200@sugarcrm.com> <AANLkTi=okFXPw6=0p0mPK5LCAzh_-65uZpD13-C6rfJA@mail.gmail.com>
 <AANLkTinEne8Rq-Ew+=GsC_DF0x8D0FP8XmjRB_txpQXE@mail.gmail.com>
 <8b46dd8e3e991cfe87550a9c55d9ecd8.squirrel@webmail.basnetworks.net>
 <AANLkTik2aL0UVVoy0WxamUaqPgwUtKV3Y-RQYPOtf6j-@mail.gmail.com>
 <4814e263cbd2b09767ca16908dd4ee01.squirrel@webmail.basnetworks.net>
 <AANLkTi=iNiOJK5WXqiwpdCbffw9QqywhgTUur6vRnmEJ@mail.gmail.com> <e423a80669e2045f17b5febc4bb7edd2.squirrel@webmail.basnetworks.net>
Date: Mon, 6 Dec 2010 11:12:19 +0000
Message-ID: <AANLkTimiWQMJ0O3L3s28VkgZJCWhFHxi3T_6hurCSLmA@mail.gmail.com>
To: president@basnetworks.net
Cc: Eloy Bote Falcon <eloybote@gmail.com>, Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
From: rquadling@gmail.com (Richard Quadling)

On 5 December 2010 16:47,  <president@basnetworks.net> wrote:
> If I have an object called "PiggyBank", with the property "dollars" set t=
o
> 5, "dimes" set to 4 and "nickles" set to 1, then I get the contents of th=
e
> property "Total", I can predict it will give me the value 5.45. =C2=A0Tha=
t is
> what properties are really for.

To me, the "balance" on my piggy bank is a readonly, dynamic attribute/prop=
erty.

OK. Piggy bank is too small an entity. My kids' piggy banks have only
1 user per bank. The balance changes rarely 'cause they don't do a lot
of housework. Yet.

But for a larger entity, something with many people altering data via
an "instrument of change" (a term I got from Sage Accounting a long
time ago), then the "balance" on an account will change in unknown
ways.

And a synthetic property like "AvailableBalance" will certainly look
like a random value, whilst orders are taken during the day and
invoices raised and payments allocated. All in real time. A real world
process.

What I'm confused by is what you would consider a property? Why does
predictability matter? Not all properties of an entity are
predictable. My kids have an attribute of "mood". They sure as hell
aren't predictable.

If you have a clock object, the "time" is a readonly, dynamic
property/attribute of a clock. Makes sense?

You would want $clock->time as a property. Not $clock->getTime().
Well. OK. You _COULD_ and it would solve all the issues you have with
dynamic, readonlys, but "time" is a property.

What would you expect to be the natural behaviour of unset($clock->time); ?

If I have to call getTime(), then I've just got setters/getters
(__magic will do). Suddenly time is no longer a property of a clock.



I can see we have very different opinions about the implementation and
the possible use of properties. I'm quite happy with that. Either way,
I think the basic proposal is very good. I've always wanted
setters/getters in PHP specifically to implement readonly/writeonly
attributes when I went from Delphi to PHP. The concept of grouping
these together into a "property" (like C#), rather than having actual
set and get methods (like Delphi) certainly does keep things together.
I think being able to call the getter/setter as part of fluid
interface would be useful. For each property, there would be getxxx,
setxxxx, issetxxxx, unsetxxxx. That may look useful and I think for
those that build classes like ORM systems, then probably of no issue
and would be a major feature. But maybe too much for others not using
that level of technology.

As you can see, I'm not happy with having to keep with a "method" to
update what I would consider a "property" (semantics and all that).
I'm not happy with isset() calling the getter. But I'll adapt. I don't
have the core knowledge or experience to argue much beyond what I've
already said.

The only thing I can think of though is __get can return a seemingly
random value for an undefined property. In keeping with that, why
couldn't a real property? In PHP's terms (not C#), what's the
difference?

Richard.

--=20
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY