Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102853
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
MIME-Version: 1.0
References: <8916EC21-D368-40F8-9ABD-CE0C04A73539@gmail.com>
 <CA+kxMuRBa7YFvH3sW4aALv43vumsXthfdNkNXe=_DU7dzwUA2w@mail.gmail.com>
 <0AA3251E-A0D8-492E-AEAC-3B2FBBFDB944@gmail.com> <CA+kxMuQ4FMS5Ob1aoe2mNLYokYht64Bax7k8oKTa60kjMpz+4w@mail.gmail.com>
 <F0ECBE85-8D8F-4EF5-88C0-A4B7E94E4866@gmail.com> <CADyq6sKNPQeqRtLOO5bpH+hM=ngwt7fn3p2srN0qEO7i3xax=A@mail.gmail.com>
 <CALKiJKroFzn1C6x1xGO1MtVJ9h-ebwXjSS9NGa9kmghT-iyiQg@mail.gmail.com>
In-Reply-To: <CALKiJKroFzn1C6x1xGO1MtVJ9h-ebwXjSS9NGa9kmghT-iyiQg@mail.gmail.com>
Date: Mon, 16 Jul 2018 17:42:04 +0200
Message-ID: <CADyq6sKDaTkLwo7z=_kYy0+XpVOVp0esqhAvCPX2sPiDxyO46g@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007aef2105711fac47"
Subject: Re: [PHP-DEV] Non-nullable properties
From: ocramius@gmail.com (Marco Pivetta)

--0000000000007aef2105711fac47
Content-Type: text/plain; charset="UTF-8"

There are naturally 3 states in the engine:

 1 - value set
 2 - value not set (default `null`)
 2 - undefined/uninitialised

These have been around since 5.0 AFAIK.

On Mon, 16 Jul 2018, 16:55 Rowan Collins, <rowan.collins@gmail.com> wrote:

> On 16 July 2018 at 14:28, Marco Pivetta <ocramius@gmail.com> wrote:
>
> > These don't really need explicit tests in most cases, but rather static
> > analysis (currently happening via docblocks). Static analysis tools like
> > vimeo/psalm already pick this up.
> >
>
>
> Then why do we need the type hints at all?
>
>
>
>
> > I'd even be happy to get type hints that only have effect on
> > `ReflectionProperty#getType()` as a massive improvement over the current
> > situation we've monkey-patched us into, but the patch is indeed
> consistent
> > with PHP's current state.
> >
>
>
> I disagree that it's consistent. It introduces an entirely new kind of null
> reference ("declared but uninitialised"), which will require *more* careful
> checks than forcing the value to be initially null, and will undoubtedly
> further annoy those who already claim that isset() is broken (the RFC
> doesn't even mention it, but I presume uninitialised properties will return
> false from isset(), but throw an error from is_null()).
>
> If all typed properties require a valid default value, the patch is
> simpler, errors are raised at a line where you can fix them, and the
> language remains consistent - if you're promised a Foo, you get a Foo, not
> a "whoops, why isn't there a Foo here?" error.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

--0000000000007aef2105711fac47--