Null value not set on deserialization

[Jan Drábek]

When null is passed present in deserialized data it is not deserialized and the property remains uninitialized.

Detailed description

Consider this DTO:

class FooDTO {
public function __construct(public ?array $testExamples) {}
}

And this payload

['testExamples' => null]

The expected outcome is that the instance of FooDTO will have null set into $testExample property, but currently following error happens on access:

$testExamples must not be accessed before initialization

Context

This is important behaviour to be fixed as changing structure to = null at declaration is undesired at most cases.

Possible implementation

Fix implementation of assign.

Your environment

• PHP 8.1

[Jan Drábek]

I am preparing a PL to tackle this though... it seems pretty straight forward on the scalar types, yet the behaviour on flattened types should be specified as I believe is currently undocumented.

An example:

class NDTO {
    public ?string $ga;
}
class FooDTO {
    #[Field(serializedName: 'foo6', flatten: true)]
    public ?NDTO $foo6;
}

and payload

['ga' => null]

Currently the library outputs

class FooDTO#32 (6) {
  public ?NDTO $foo6 =>
  class NDTO#33 (1) {
    public ?string $ga =>
    *uninitialized*
  }
}

Which seems quite odd... as I would expect foo6 to be null, though it could get complicated when there are values of the flatten DTO.

Second though: I would expect the foo6 equal null in case that no flattened properties are present, if any is present then the DTO should be present with and present fields should have the values (null also).

[Larry Garfield]

I just got bitten by this myself, although the error pathway seems different. I'm not entirely sure why yet.

[Rob Landers]

Which seems quite odd... as I would expect foo6 to be null, though it could get complicated when there are values of the flatten DTO.

If ['ga' => null] then I would expect foo6 to be set and ga to be null, but if passed [] then I would expect foo6 to be null.

[Larry Garfield]

Another attempt at a solution #25.

As noted there, I'm not convinced this should be solved.