Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93583
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
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>
Message-ID: <57474F9C.6080104@lsces.co.uk>
Date: Thu, 26 May 2016 20:33:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <6f7403b6-bf22-a12b-dfb2-43fe82983e7d@fleshgrinder.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: lester@lsces.co.uk (Lester Caine)

On 26/05/16 20:16, Fleshgrinder wrote:
> On 5/26/2016 9:10 PM, Lester Caine wrote:
>> DateTime is probably a better example to work with than 'int' since it
>> already has a long pedigree of problems and clashes where many projects
>> had their own interpretation and still use their own version of the
>> class. My problem with '\DateTime $d' is that by default it returns
>> 'now' rather than an 'empty/null' value in which to put the data from
>> the database. I can't create a 'null' version of DateTime so one has to
>> have a phantom date simply to ensure you know if it has been initialized
>> with your own data later - or continue to use the older user space classes.
>>
>> It is handling just how the variable/property is initialized that is the
>> whole problem here and there may be very good reasons that the
>> initialization is later then the 'construct' be that a DateTime or an
>> int ... null is the correct way of indicating that 'as yet we do not
>> have the value of type xxx' just as it does for an untyped value, so
>> trying to make a special case to block it's use is simply strangling
>> normal usage in other cases?
> 
> Could you come up with some example code of what you cannot achieve? I
> cannot think of a single situation that is valid and not a developer
> error which would be impossible with the currently discussed approach.

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?

-- 
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