Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126327
Precedence: bulk
MIME-Version: 1.0
References: <CAJWOiuNQ+ue-ZyY3EfnEQGo9JJ5mjf=tByxp31M__N71_ODy6A@mail.gmail.com>
 <CALWFqqBFJr2E-8s7eGsZ=MOFGpaa7rsgcqrSU0QB5g6zs_yRdQ@mail.gmail.com> <81ba09d5-d8fa-4c26-8ef0-d4b7bf0de52a@app.fastmail.com>
In-Reply-To: <81ba09d5-d8fa-4c26-8ef0-d4b7bf0de52a@app.fastmail.com>
Date: Fri, 7 Feb 2025 16:40:09 +0500
Message-ID: <CALWFqqBOk+JNnBiiYAP+aBe6bhCjaHvx2f7wTdx9vNA1J-QePw@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: Not Null Assertion Operator
To: Rob Landers <rob@bottled.codes>
Cc: Mihail Liahimov <91liahim@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: ilyaorlov124@gmail.com (MrMeshok)

> Hello,
>
> I feel like that is more of an architecture problem than a programming on=
e though. Instead of constantly checking if the conditions are right, use p=
hp's type system instead, so it would read more like:
>
> if ($response instanceof SuccessfulResponse) {
>   return $response->data->order->quantity;
> }
>
> throw new UnexpectedResponseException($response);
>
> I'd argue that having an "undefined" aka "null" quantity in a model at al=
l is rather strange as that doesn't seem to represent any possible reality =
outside of a computer (unless you are dealing with Schrodinger's cat or oth=
er quantum effects).
>
> =E2=80=94 Rob

Hi,

The thing is I am just a consumer of the API, before implementing I
did have a thought about having Successful and Error DTOs, but for me
that was more work for the same result. First I need to map JSON to
generic Response, then do some checks and map from generic Response to
another DTO. And it's not just success and error, there are about 20
response codes and several variations of response you could get.
And I absolutely agree about null quantity, some of the objects there
have every property nullable, it's insane.