On 27/05/2021 17:13, Andreas Leathley wrote:
How is "uninitialized" magic? It is a state of a class property in PHP
that is currently being exposed via reflection
Apologies if my last message was a bit too hastily written, and may have
come across as rude.
What I meant by it being "magic" is that it can't be represented by any
value or type. A lot of the examples in this thread attempt to use
"uninitialized" like it was an extra value for the variable, as though
the type of the property was "int|null|uninitialized". But that can't be
declared in the property's type, and I don't know if there's even a
docblock convention for "note that this property might be deliberately
uninitialized, when it is, that means this ...".
Since we now have union types, you can actually be a lot more explicit
about the extra state, and use something like "int|false|null"; in 8.1,
you'll also be able to use "int|SomeEnum|null". Since those are real
types, with real values, no extra functions need to be added to the
language, and everything feels a lot less "magic".
I have seen quite a
few places where it occurs - for example with setter injection in
frameworks, as an alternative to setting a property in the constructor.
Just to reiterate, the new function would *only* be useful if you were
trying to distinguish the uninitialized state from a null value.
If you have a property which you *know* might not be provided, you
already have "null" to represent that. For instance, a property that
might hold an instance of LoggerInterface, but only if the user calls a
setLogger method, can be declared as "?LoggerInterface $logger=null",
and tested with "isset($this->logger)".
PS: A much sillier reason why I hate "uninitialized" is that I
consistently misspell it as "unitialized" :P
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
