Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102860
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c-N0N3QbpY2ie=iaPLyzRjpm7ykq=BAp=GchkQfs_nWoA@mail.gmail.com>
References: <8916EC21-D368-40F8-9ABD-CE0C04A73539@gmail.com> <CAF+90c-N0N3QbpY2ie=iaPLyzRjpm7ykq=BAp=GchkQfs_nWoA@mail.gmail.com>
Date: Mon, 16 Jul 2018 17:51:24 +0100
Message-ID: <CALKiJKosHoi7rssvXTj9d+G-VP==sNusyLZDxOs5uM0Hexw-WA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d7a6ba057120a318"
Subject: Re: [PHP-DEV] Non-nullable properties
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000d7a6ba057120a318
Content-Type: text/plain; charset="UTF-8"

On 16 July 2018 at 17:20, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Sat, Jul 14, 2018 at 3:09 PM, Rowan Collins <rowan.collins@gmail.com>
> wrote:
>
> If I have an instance $v of that class, I would expect to be able to
>> safely call $v->validFrom->getTimestamp(), but need to check for nulls
>> before doing the same with validTo. Under the current proposal, doing so
>> will risk errors, so I will have to check both properties before access
>> anyway. Worse, using is_null() or ?: will attempt to retrieve the value, so
>> I actually have to be *more* careful, and use isset() or ?? instead.
>>
>
> I'm just going to reply to this one line, because this is the root of your
> misunderstanding:
>
> The user should never, ever, under any circumstances (*) check for the
> initialization of a typed property.
>


Agreed. Which is why the language should guarantee that they don't need to.




> The user simply uses the property under the firm knowledge that it will be
> initialized -- or there is a bug in the initialization code. If there is a
> bug in the initialization code then it needs to be fixed there, not by
> introducing a check when working with the object.
>


Absolutely. But in order for that to happen, the error needs to be shown to
the author of that code, not to some downstream user who will have no way
to fix it.


As I mentioned before, I see no practical difference between seeing this
comment in a library...


/**
 * You can rely on this property being initialised to a non-null value in
the constructor
 */
public ?Foo $foo = null;


... and seeing this declaration under the current proposal ...


public Foo $foo;


In both cases, as the user of the library, I'm entirely at the mercy of the
library author to implement the documented behaviour. If I trust them, and
use the property without checking it, I risk errors if they have made a
mistake, which I can't fix.




>
> Please do also remember that uninitialized properties and unset properties
> are the same thing
>


No they're not, an unset property doesn't raise an error when you try to
access it; see my last e-mail to Marco.


Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000d7a6ba057120a318--