On 26/05/16 20:56, Rowan Collins wrote:
> 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
I think what is irritating here is that actually both of these can still
validly be null. It's HAVING to add the ? to every item when actually by
conventions 'NOT NULL' is the exception. Would ? indicating 'NOT NULL'
actually be better since it IS only adding that flag which is required
here to block the use of null?
> // accessing $me->marriage or $me->death returns NULL (because they
> allow nulls) but raises E_NOTICE
BUT DateTime currently will not store 'null' - it returns 'now' instead.
We end up having to store string or integer values because we can't
store a null date :(
> 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
The suggestion I was seeing was that a 'NOT NULL' value had to be
initialized. I think my problem is perhaps is just what errors are
created that break the normal flow and what gets returned when checking
to see IF a value has been initialised.
$me->numSiblings would actually be null in this case if it has not yet
been established since the answer may well be '0' but that just explains
why null is still valid even for an int property. We just have no idea
if it's null because it's just been created or because the database read
returned 'null'.
The alternate 'not null' value is more clear cut in that 'null' can mean
that it is uninitialized, and one needs to run the initialization code
for it. I need is_null($me->numSiblings) to work and return true so I
can select the initialization code, or should there be a new state of
'uninit' as well? Then if we want to 'reset' the person object do the
'not null' entries get rest to null so they can be re-initialized.
'unset' the person does not remove the object simply rewinds it to an
unset state ... so should unset of these typed properties do that or do
we actually need an uninit?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
