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.
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
