Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93613
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <57483EC9.3000501@lsces.co.uk>
References: <20160525215208.034FC1A801B3@dd1730.kasserver.com> <e194be7d-2d72-945c-b8de-245e91f6f239@thefsb.org> <CAO3MkaD==1jQvS_cRbDrBQ7nkoBvoAaavmgxeMiP0mSKXL7eRQ@mail.gmail.com> <D36C9366.6E7CA%fsb@thefsb.org> <5fd54aa0-4fdf-c1e7-eae8-765aa89c8498@fleshgrinder.com> <cb4f05df-c5fa-68db-453a-274d42c2c15e@gmail.com> <08963b03-8394-6d62-4e5b-393f3fcb5647@fleshgrinder.com> <9e9db70d-d72d-d93e-0c81-18c2aa228618@gmail.com> <409002d8-b5e3-5990-7358-246adc7e3cab@fleshgrinder.com> <57474A08.80807@lsces.co.uk> <6f7403b6-bf22-a12b-dfb2-43fe82983e7d@fleshgrinder.com> <57474F9C.6080104@lsces.co.uk> <1733cfce-001b-1079-e929-88f7dde0f2dd@gmail.com> <57475F27.3090306@lsces.co.uk> <34edcbd1-2d6a-cd52-7bbb-c393ab62d32d@gmail.com> <574772BA.3030305@lsces.co.uk> <a6d08adb-198f-4696-3b25-2790480ce1f6@gmail.com> <5748164C.7020803@lsces.co.uk> <5156d2d3-6c7b-b5d0-fdfd-9064d8fb1d58@fleshgrinder.com> <57483EC9.3000501@lsces.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Fri, 27 May 2016 18:43:31 +0100
To: Lester Caine <lester@lsces.co.uk>,internals@lists.php.net
Message-ID: <80160E82-0C48-4A20-8594-8F12E2D7174B@gmail.com>
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: rowan.collins@gmail.com (Rowan Collins)

On 27 May 2016 13:34:17 GMT+01:00, Lester Caine <lester@lsces.co.uk> wrote:
>Hence the 'in an ideal world'! It is perhaps worth making clear that a
>'typed property' element IS simply a holder for the pointer to the real
>element while the untyped properties are the element themselves?

In database terms, a property - typehinted or not, scalar, whatever - is like a column. On a particular instance (= row) each property will have some particular value.

Consider how "father" would be modelled as a foreign key in the DB. If you don't know the father, you would insert a null, not reference a special row representing The NullFather. And if you discovered the father was incorrect, you would update the row to point at a new record, not change the name on the old father record - it is not the name that was incorrect, only the relationship.

So in OO you do the same: if you don't know the father, you store a null in that field. If you want to change the father, you point at a new object, you don't go in and edit the existing one.

$this->father = $newFather;

There's no "empty object" here, no need to "reset" the object which was incorrectly assigned to the father property, just a new association representing the corrected information.

-- 
Rowan Collins
[IMSoP]