Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114624
MIME-Version: 1.0
References: <CAOwTYAtc_xD6n=efmamkAy4ro4KqPKxq18-zXsNriY0280FY2g@mail.gmail.com>
 <80fb5a8e-d770-49fd-45d5-ea6f4b004513@gmail.com> <2874cf7c-e55d-4100-bb01-af11a5ab6e87@www.fastmail.com>
 <CAC5V6ghyHFrrvgL_rXQKAKt1KMAVCRbGxhQb4Ouqojn474jLMQ@mail.gmail.com>
In-Reply-To: <CAC5V6ghyHFrrvgL_rXQKAKt1KMAVCRbGxhQb4Ouqojn474jLMQ@mail.gmail.com>
Date: Wed, 26 May 2021 21:24:07 +0200
Message-ID: <CABdc3WrC-qX8sXpvQD1f6UZYCTko5Cjd3C_e4O2ODPeJ9NecDQ@mail.gmail.com>
To: Guilliam Xavier <guilliam.xavier@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c9e4bb05c34096e9"
Subject: Re: [PHP-DEV] Consensus Gathering: is_initialized
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--000000000000c9e4bb05c34096e9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=C5=9Br., 26 maj 2021 o 18:20 Guilliam Xavier <guilliam.xavier@gmail.com>
napisa=C5=82(a):

> On Wed, May 26, 2021 at 4:09 PM Larry Garfield <larry@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=3D78480
> > > >
> > > > I implemented: https://github.com/php/php-src/pull/7029
> > >
> > >
> > > My general feeling remains that the "uninitialized" state is an awkwa=
rd
> > > hack that we should be working to eliminate with better constructor
> > > semantics. A variable that remains uninitialised after the constructo=
r
> > > almost always indicates a bug in the constructor, not a state that th=
e
> > > rest of the application should care about.
> >
> > I am inclined to agree here.  What I don't know about is the cases note=
d
> > in the bug, such as GraphQL or other serialization cases where "null" a=
nd
> > "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 construct=
or
> (then the DTO is passed through validation, which must handle uninitializ=
ed
> 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 =3D ['name' =3D> 'main_window','width' =3D> 500,'height' =3D> 500];
class Window {
    public function __construct(
        public string $title,
        public string $name,
        public int $width,
        public int $height,
        public ?bool $unknown =3D 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 =3D null,
        public string $name,
        public int $width,
        public int $height,
        public ?bool $unknown =3D 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=C5=82 Marcin Brzuchalski

--000000000000c9e4bb05c34096e9--