Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93581
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>
Message-ID: <57474A08.80807@lsces.co.uk>
Date: Thu, 26 May 2016 20:10:00 +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: <409002d8-b5e3-5990-7358-246adc7e3cab@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 18:26, Fleshgrinder wrote:
> On 5/26/2016 7:20 PM, Rowan Collins wrote:
>> > I think the difference is the emphasis of whose responsibility it is to
>> > fix it: a TypeError confirms that the error is in the O class for
>> > exposing an incorrectly typed property; a NullPointerException, as you
>> > put it, makes it my fault for trusting the class.
>> > 
>> > Or to put it a different way, is the error in the first arrow (accessing
>> > "->d") or the second one (de-referencing "d->").
>> > 
>> > 
>> > At the end of the day, all the type notations being added to PHP are
>> > just assertions anyway. So the same could be said of this:
>> > 
>> > function foo(\DateTime $d) {
>> >    echo $d->format('Y-m-d H:i:s');
>> > }
>> > foo(null);
>> > 
>> > If this didn't throw an error at "foo(null)", it would throw an error at
>> > "$d->format".
>> > 
> Yes, they are just assertions and design by contract and you make a very
> good point here for an actual error. I am convinced. ;)
> 
> However, it should not throw an error for isset() and empty() to allow
> more special constructs. As we already have it in place everywhere with
> the two.

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?

-- 
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