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