Re: [PHP-DEV] Non-nullable properties

On Thursday, July 19, 2018 10:01:58 AM CDT Rowan Collins wrote: > On 19 July 2018 at 15:20, Christoph M. Becker wrote: > > It seems to me that either of these proposals would render the lazy > > initialization pattern outlined in the “Overloaded Properties” > > section[1] invalid. > > > > [1]

Re: [PHP-DEV] Non-nullable properties

On 19 July 2018 at 15:20, Christoph M. Becker wrote: > It seems to me that either of these proposals would render the lazy > initialization pattern outlined in the “Overloaded Properties” > section[1] invalid. > > [1] > Hm, I

Re: [PHP-DEV] Non-nullable properties

On 19.07.2018 at 15:41, Rowan Collins wrote: > On 16 July 2018 at 17:09, Larry Garfield wrote: > >> class Foo { >> >> protected Bar $b; >> >> // This runs before __construct, is not inherited, and cannot >> // ever be skipped. If this method exits and any property is still >> // value-l

Re: [PHP-DEV] Non-nullable properties

On 16 July 2018 at 17:09, Larry Garfield wrote: > class Foo { > > protected Bar $b; > > // This runs before __construct, is not inherited, and cannot > // ever be skipped. If this method exits and any property is still > // value-less, TypeError immediately. > protected function __init

Re: [PHP-DEV] Non-nullable properties

On 16 July 2018 19:42:49 BST, Stanislav Malyshev wrote: >Hi! > >> I agree with you. If someone really wants to have an "uninitialized" >field >> on purpose, they should do that using the correct type declaration, >i.e.: >> >> ?MyType $myNullable = null; >> >> When this was started I asked if it

Re: [PHP-DEV] Non-nullable properties

Hi! > I agree with you. If someone really wants to have an "uninitialized" field > on purpose, they should do that using the correct type declaration, i.e.: > > ?MyType $myNullable = null; > > When this was started I asked if it was possible to check types right after > object has been construct

Re: [PHP-DEV] Non-nullable properties

On 16 July 2018 at 17:24, Wes wrote: > It's more strict in the proposed rfc. In particular in java the error is > allowed to propagate in the program, while here it won't be. > In other words if ` $foo->aaa` is uninitialized, you are not allowed to > do ` $baz->bbb = $foo->aaa`. > In java that's

Re: [PHP-DEV] Non-nullable properties

On 16 July 2018 at 17:20, Nikita Popov wrote: > On Sat, Jul 14, 2018 at 3:09 PM, Rowan Collins > 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

Re: [PHP-DEV] Non-nullable properties

It's more strict in the proposed rfc. In particular in java the error is allowed to propagate in the program, while here it won't be. In other words if ` $foo->aaa` is uninitialized, you are not allowed to do ` $baz->bbb = $foo->aaa`. In java that's allowed, so in java null pointer deref can really

Re: [PHP-DEV] Non-nullable properties

On Sat, Jul 14, 2018 at 3:09 PM, Rowan Collins wrote: > Hi all, > > As briefly mentioned, I think the approach to non-nullable types in the > typed properties proposal needs more discussion, to make sure we're not > repeating Tony Hoare's "billion-dollar mistake". > > For parameter hints, nullabi

Re: [PHP-DEV] Non-nullable properties

On 16 July 2018 at 17:07, Wes wrote: > This is definitely not as bad as the "billion dollar mistake" though. The > error still happens, but in a different place. > That's exactly what happens in most languages, isn't it? An error happens when you try to resolve a null reference, but by then it'

Re: [PHP-DEV] Non-nullable properties

On Monday, July 16, 2018 9:55:31 AM CDT Rowan Collins wrote: > On 16 July 2018 at 14:28, Marco Pivetta 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 u

Re: [PHP-DEV] Non-nullable properties

I agree with you. If someone really wants to have an "uninitialized" field on purpose, they should do that using the correct type declaration, i.e.: ?MyType $myNullable = null; When this was started I asked if it was possible to check types right after object has been constructed, but they said i

Re: [PHP-DEV] Non-nullable properties

On 16 July 2018 at 16:42, Marco Pivetta wrote: > There are naturally 3 states in the engine: > > 1 - value set > 2 - value not set (default `null`) > 3 - undefined/uninitialised > > These have been around since 5.0 AFAIK. > "Undefined" and "uninitialised" are not the same state: class A {

Re: [PHP-DEV] Non-nullable properties

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, wrote: > On 16 July 2018 at 14:28, Marco Pivetta wrote: > > > These don't really need e

Re: [PHP-DEV] Non-nullable properties

On 16 July 2018 at 14:28, Marco Pivetta 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

Re: [PHP-DEV] Non-nullable properties

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. I'd even be happy to get type hints that only have effect on `ReflectionProperty#getType()` as a massive improvement ov

Re: [PHP-DEV] Non-nullable properties

On 16 July 2018 13:00:57 BST, Dan Ackroyd wrote: >On 16 July 2018 at 09:43, Rowan Collins >wrote: > >> There's no contradiction here; throwing an error when a >> property is *read* is not the same as enforcing that it always has a >valid value. > >That's true, but claiming the RFC just 'trusts' t

Re: [PHP-DEV] Non-nullable properties

On 16 July 2018 at 09:43, Rowan Collins wrote: > There's no contradiction here; throwing an error when a > property is *read* is not the same as enforcing that it always has a valid > value. That's true, but claiming the RFC just 'trusts' the users to initialise them is a miss-representation of

Re: [PHP-DEV] Non-nullable properties

On 16 July 2018 00:52:53 BST, Dan Ackroyd wrote: >On 14 July 2018 at 14:09, Rowan Collins >wrote: >> Hi all, >> >> The current RFC proposes the next simplest solution, which is to >allow non-nullable types, and trust the user to initialise them before >use. > > >From the RFC: >> If a typed proper

Re: [PHP-DEV] Non-nullable properties

On 14 July 2018 at 14:09, Rowan Collins wrote: > Hi all, > > The current RFC proposes the next simplest solution, which is to allow > non-nullable types, and trust the user to initialise them before use. >From the RFC: > If a typed property does not have a default value, no implicit null defaul

Re: [PHP-DEV] Non-nullable properties

On 14 July 2018 19:29:23 BST, Levi Morrison wrote: >Whether it's a constructor, a factory method, or just a block of code >near the `new` site: something has the responsibility for >initialization. Indeed, and my suggestion is to formalise that responsibility, so that mistakes can be detected cl

Re: [PHP-DEV] Non-nullable properties

On Sat, Jul 14, 2018 at 10:00 AM Rowan Collins wrote: > > On 14 July 2018 15:37:32 BST, Levi Morrison wrote: > >> class Validity { > >> public \DateTimeInterface $validFrom; > >> public ?\DateTimeInterface $validTo = null; > >> } > > > >Even if this had a constructor we couldn't "trust" i

Re: [PHP-DEV] Non-nullable properties

On 14 July 2018 15:37:32 BST, Levi Morrison wrote: >> class Validity { >> public \DateTimeInterface $validFrom; >> public ?\DateTimeInterface $validTo = null; >> } > >Even if this had a constructor we couldn't "trust" it because there >are ways to skip constructors. Then the mechanisms sh

Re: [PHP-DEV] Non-nullable properties

On Sat, Jul 14, 2018 at 7:09 AM Rowan Collins wrote: > > Hi all, > > As briefly mentioned, I think the approach to non-nullable types in the typed > properties proposal needs more discussion, to make sure we're not repeating > Tony Hoare's "billion-dollar mistake". > > For parameter hints, nulla