> > 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