śr., 26 maj 2021 o 18:20 Guilliam Xavier <guilliam.xav...@gmail.com> napisał(a):
> On Wed, May 26, 2021 at 4:09 PM Larry Garfield <la...@garfieldtech.com> > wrote: > > > On Wed, May 26, 2021, at 8:24 AM, Rowan Tommins wrote: > > > On 26/05/2021 11:13, Joe Watkins 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
