Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50872
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basnetworks.net from 208.97.132.5 cause and error)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; c=nofws; d=basnetworks.net; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:mime-version
	:content-type:content-transfer-encoding; q=dns; s=
	basnetworks.net; b=fg7bvNLjbIyS8w0x5D2gcrN1O/ui0JuiYHlbNKT/IU87s
	daOdSZtvnmyFm8pnNPVb3KbDk/z28vLlqqqL9GL1YLVgw/8qcOR0f+ApZd28CDvn
	xxhxBIx/xlnqRoCk55pIyVCSNIG43M+qbGUywtDlUIvECGMWMtqNaddU7ZYYdo=
Message-ID: <4e908752c26b56b6edf417027872c623.squirrel@webmail.basnetworks.net>
In-Reply-To: <AANLkTimiWQMJ0O3L3s28VkgZJCWhFHxi3T_6hurCSLmA@mail.gmail.com>
References:
    <ae7aa0536c47a2ac725222d49918183f.squirrel@webmail.basnetworks.net>
    <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>
    <AANLkTimiWQMJ0O3L3s28VkgZJCWhFHxi3T_6hurCSLmA@mail.gmail.com>
Date: Mon, 6 Dec 2010 07:41:25 -0500
To: RQuadling@googlemail.com
Cc: president@basnetworks.net,
 "Eloy Bote Falcon" <eloybote@gmail.com>,
 "Stas Malyshev" <smalyshev@sugarcrm.com>,
 "internals@lists.php.net" <internals@lists.php.net>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
From: president@basnetworks.net

> On 5 December 2010 16:47,  <president@basnetworks.net> wrote:
>> If I have an object called "PiggyBank", with the property "dollars" se=
t
>> to
>> 5, "dimes" set to 4 and "nickles" set to 1, then I get the contents of
>> the
>> property "Total", I can predict it will give me the value 5.45. =C2=A0=
That
>> is
>> what properties are really for.
>
> To me, the "balance" on my piggy bank is a readonly, dynamic
> attribute/property.
>
> 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.

Sure, the balance is updated all the time in the database or whatever
external data source it is stored in.  But you are only loading from that
database a single time in a page load.  If you are loading it more than
once, as per the C# guidelines, you should be doing it in a method, in
order to signify that it is a resource intensive operation (makes a call
to the data store every time its accessed... that is too intensive for a
property, at least as agreed by the C# folks).

Besides, this is not a common scenario.  For the most part, if people are
loading from a datastore, they will only load the data once per page, the=
n
cache it within the object instance.


> 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.

Yes, you would want it as a property.  It is very predictable, as it give=
s
you the current time of the clock.  Lets say you call $clock->addHours(1)=
,
when you call $clock->time, you can expect it to be an hour further
forward.  If the clock is currently running, you can expect it to be one
second higher for every second that passes.  If $clock->time is being
loaded from a datastore once per second where it could get modified, that
is not predictable.  Instead you should have
$clock->syncTimeFromDataStore() or some such.  Once you call that method,
you know $clock->time is going to be modified.


> What would you expect to be the natural behaviour of unset($clock->time=
);?

I would guess that it just would not do anything.  Either that or throw a
non-fatal error.  The user would have to know that the property is
readonly, which they can do by looking at the documentation or the class
definition.

I think you mention this in the interest of the interchangeability of
properties and variables.  I suppose we cannot have full 100%
interchangeability if we still want separate visibility levels
(public,protected,private) on the get/set, and the possibility of
readonly/writeonly.

I think that the interchangeability of the two would be like so:

- A property can always be replaced with a variable, even if the new
property has separate visibility levels (or final, abstract) on its get
and set methods, and will continue to "work".
- A variable can be replaced by a property and be guaranteed to "work" as
long as the new property does not have separate visibility levels (or
final, abstract) on its get and set methods.


> 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?

A property certainly could return a random value, and it is perfectly
"valid" to do so.  But as a guideline its not recommended.  As a concept,
properties and fields (public variables) are supposed to tell you
something about the object instance.  They are an "attribute" of the
object.  If they don't produce predictable results, than they cease to
tell you about the object.  You should always create a method if you are
going to "generate" an unpredictable value.  This is a convention that
makes coding with the C# libraries a joy, because properties always work
in a predictable manner, and you know they will never give you some wild
value.

- Dennis