>
> Hey Niklas,
>
> > Am 25.05.2016 um 18:21 schrieb Niklas Keller <m...@kelunik.com>:
> >
> >>
> >> Hi Niklas,
> >>
> >> Niklas Keller wrote:
> >>
> >>>
> >>> I disagree here. Properties are always null by default. The current
> patch
> >>> disallows
> >>> access to uninitialized variables only if they're not nullable, since
> null
> >>> isn't a valid value then.
> >>>
> >>> I don't think having to explicitly set them to null is the think we
> want.
> >>> And it's not what I'd expect given the current system.
> >>>
> >>
> >> PHP's existing untyped properties are implicitly initialised to null,
> and
> >> so yes, we would essentially only be copying our existing behaviour.
> >>
> >> However, I think it is worth asking whether our existing behaviour is
> >> useful before we preserve it here. From my perspective, it is unhelpful
> >> that PHP does not warn you about using properties you haven't
> initialised,
> >> and this applies to both typed and untyped properties. In some cases
> (like
> >> in my linked list example in a previous email), null might be a
> meaningful
> >> value and worth distinguishing from a property not having being
> initialised
> >> yet.
> >>
> >
> > Null shouldn't have any meaning apart from "not set". It should never be
> a
> > meaningful value.
> >
> >
> >> We can't change the behaviour of our existing untyped properties (or at
> >> least, that's beyond the scope of this RFC), but we could choose the
> >> behaviour we find more useful for our typed properties.
> >>
> >> Consider that we did something like this for parameters. Not providing
> an
> >> untyped parameter gives an E_WARNING:
> >>
> >> $ php -r 'function foo($a) {} foo();'
> >> PHP Warning: Missing argument 1 for foo(), called in Command line code
> on
> >> line 1 and defined in Command line code on line 1
> >>
> >> But not providing a typed parameter gives a TypeError:
> >>
> >> $ php -r 'function foo(int $a) {} foo();'
> >> PHP Fatal error: Uncaught TypeError: Argument 1 passed to foo() must be
> >> of the type integer, none given, called in Command line code on line 1
> and
> >> defined in Command line code:1
> >> Stack trace:
> >> #0 Command line code(1): foo()
> >> #1 {main}
> >> thrown in Command line code on line 1
> >>
> >> So there's a precedent for applying stricter rules when type
> declarations
> >> are used.
> >>
> >> Thanks!
> >>
> >>
> >> --
> >> Andrea Faulds
> >> https://ajf.me/
>
> There is a difference between not set and no meaningful value.
>
> The former is literally unset(), the latter is null. The only semantics
> PHP exposes here is that not set can be upgraded to "no meaningful" value
> in form of null with a notice.
>
> The difference thus is quite minor, but semantically important.
> Hence to *set* the value, we need to explicitly set null.
>
Adding a type shouldn't alter behavior, so setting it explicitly to null
shouldn't be required.
Regards, Niklas
> If we don't do it this way, we won't have a way to explicitly *set*
> nullable properties to a value (null in this case). (without explicit unset
> in ctor).
>
> Bob
