Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93584
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
To: internals@lists.php.net
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>
Message-ID: <1733cfce-001b-1079-e929-88f7dde0f2dd@gmail.com>
Date: Thu, 26 May 2016 20:56:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <57474F9C.6080104@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: rowan.collins@gmail.com (Rowan Collins)

On 26/05/2016 20:33, Lester Caine wrote:
> If I am creating an object which is a 'person' for which I actually want
> to ensure I have valid dates for birth, marriage and death and an
> integer 'no of siblings' then I have a set of 'typed' properties.
> Initially the object is not initialized ... no person found in the
> database ... so null values for every property in the object. When I
> search and find a match, then I may get someone who is 'alive' so the
> death property remains null. Currently one can not use DateTime
> variables to do any of this as they have already defined their own
> alternative to null by blocking it. So in this case it is pointless
> trying to create any 'can be null' flag? Class variables are simply not
> handling the problem consistently so one has to jump through hoops to
> get back what used to be a simple null initialised set of properties?

The current proposal (or the one which I am advocating) for that is that 
you would have something like the following:

class Person {
     public \DateTime $birth;
     public ?\DateTime $marriage;
     public ?\DateTime $death;
     public int $numSiblings;
}

Creating an object would leave it in an invalid state:

$me = new Person;
// accessing $me->birth or $me->numSiblings is an error in this state, 
because defaulting to NULL would violate their type constraint
// accessing $me->marriage or $me->death returns NULL (because they 
allow nulls) but raises E_NOTICE

Now you can initialise the mandatory fields:

$me->birth = new \DateTime($db_record['birth_date']);
$me->marriage = new \DateTime($db_record['marriage_date']);
$me->death = new \DateTime($db_record['death_date']);
$me->numSiblings = $db_record['num_siblings'];
// all properties can now be safely accessed
// $me->marriage and $me->death may still be null, as indicated by the 
"?" in their type spec
// $me->birth is guaranteed to be a \DateTime object

Regards,

-- 
Rowan Collins
[IMSoP]