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"). -- Guilliam Xavier
