Consensus Gathering: is_initialized

I think you said the word: serialization. And especiallydeserialization,
e.g. from a JSON payload into a typed DTOwithout calling the constructor
(then the DTO is passed through validation, which must handle uninitialized
typed properties "gracefully").

Would is_initialized() actually be all that useful there though?

• If you're iterating the properties dynamically, you'll probably be
  using the reflection API already
• If you're listing them manually, you can validate the input rather
  than the output, which you'd have to do if there's any mapping of names
  or types anyway

It's also worth noting that If the property is not nullable, you can use
isset() to tell if it's been initialised; and if it is nullable, you
probably want it to default to null anyway.

A separate function is only needed if you've decided to use the
uninitialised state as an extra "value", distinct from null.

Regards,

--
Rowan Tommins
[IMSoP]

śr., 26 maj 2021 o 18:20 Guilliam Xavier guilliam.xavier@gmail.com
napisał(a):

On Wed, May 26, 2021 at 4:09 PM Larry Garfield larry@garfieldtech.com
wrote:

Hi internals,

In response to: https://bugs.php.net/bug.php?id=78480

I implemented: https://github.com/php/php-src/pull/7029

My general feeling remains that the "uninitialized" state is an awkward
hack that we should be working to eliminate with better constructor
semantics. A variable that remains uninitialised after the constructor
almost always indicates a bug in the constructor, not a state that the
rest of the application should care about.

I am inclined to agree here. What I don't know about is the cases noted
in the bug, such as GraphQL or other serialization cases where "null" and
"absent" are not quite the same thing. That is probably sufficiently
edge-case to not deal with directly, especially when the more verbose
alternative still exists, but that's the only reason I'd even consider
making uninitialized something other than "your constructor is bad and
you
should feel bad."

I think you said the word: serialization. And especially deserialization,
e.g. from a JSON payload into a typed DTO without calling the constructor
(then the DTO is passed through validation, which must handle uninitialized
typed properties "gracefully").

I don't think nowadays anyone does that without a kind of deserializer
which
reads the metadata of desired DTO and like Symfony's Serializer or JMS
which just deal with such tasks!?

Not using ctor even for manual construction would be just a waste of time
writing validation etc.
Consider JSON decoded into:

$arr = ['name' => 'main_window','width' => 500,'height' => 500];
class Window {
public function __construct(
public string $title,
public string $name,
public int $width,
public int $height,
public ?bool $unknown = null,
...$additional,
) {}
}
var_dump(new Window(...$arr));

That example errors, since the title property is not given in decoded
payload.
The behaviour is what we expect here since we require it.
The solution is to pass a valid payload with the title.
Additionally, you can see "unknown" was also missing but it was initialized
with default null value since we don't require that.

If you add nullability into the title as follows:

class Window {
public function __construct(
public ?string $title = null,
public string $name,
public int $width,
public int $height,
public ?bool $unknown = null,
...$additional,
) {}
}

Then is passing built-in language sort of validation.

If you wanna allow passing more values than expected, add not used variadic
argument at the end.
Variadic argument solves the issue with missing named arguments which might
appear in the future.

These examples show a very simple solution to container classes such as DTO.
All of them avoid dealing with an uninitialized state.

IMHO there really is no need to deal with uninitialized properties in DTO!

Cheers,
Michał Marcin Brzuchalski

Since the argument against is_initialized() seems to almost universally be that we should not write code that lets type properties be uninitialized past the constructor then it would follow that PHP is in the wrong to even allow uninitialized state past the constructor?

Yes, that is my view. The problem is that there is currently no easy way
to enforce this, because constructors are just methods that run after
the object is created, and there are a handful of ways to create objects
without calling them at all which would need to be accounted for as well.

If a property is defined as ?int or null|int why should PHP allow an uninitialized state to begin with? Why shouldn't PHP initialize any of those properties to null to begin with?

And for non-nullable, why shouldn't PHP default int to 0, string to "", array to [], etc.?

Implicitly assigning a default from some magic list would be messy, but
requiring that the user specified one would be trivial (or would have
been, when typed properties were added): ?Foo $foo=null; int $bar=0; etc

The problem is that for non-scalar, non-nullable properties, there is no
way to specify a default. One solution would have been to simply ban
such declarations (i.e. require ?Foo $foo=null rather than Foo $foo) but
that was considered too restrictive, so marking the properties
"uninitialized" is the compromise.

We're probably stuck with that compromise for now, but continuing to
treat it primarily as an error state hopefully leaves us room to do
something cleaner in future if we can work out how.

Regards,

--
Rowan Tommins
[IMSoP]

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]