>
> if ($response->getStatusCode() > 199 and $response->getStatusCode() < 300)
> {
> // do something with “true” - which has a range of 100 possibilities at
> a granular level, which we could respond to differently - possible to
> interact with $response
>
> }
> // do something with “false” - which has a range of more than 100
> possibilities at a granular level, which we could respond to differently -
> possible to interact with $response
>
> We might wrap response to create an isOk() method to move the conditional
> logic somewhere within the object itself and make the call site more
> readable.
>
> If ($response->isOk()) {
> // do something with “true” - still able to interact with $response
>
> }
> // do something with “false” - still able to interact with $response
>
This looks way much cleaner and is easy to read and understand.
While I understand the proposed feature is opt-int it introduces more magic
that can be solved using more verbose and IMO cleaner solutions.
> With the RFC:
>
> if (new MyType($config)) {
> // do something with “true” - can’t use MyType because not assigned
>
> }
> // reachable because possible to resolve to false - if implements
> Falsifiable and __toBool can resolve to false - can’t use MyType because
> not assigned
>
> if ($response = new MyType($config)) {
> // do something with “true” - with the option of using $response
>
> }
> // reachable - can’t use MyType because may not be assigned
>
> $response = new MyType($config);
> If ($response) {
> // do something with “true” - with the option of using $response
>
> }
> // do something with “false” - with the option of using $response
>
This is somehow confusing, why is the $response storing object ref is ok
while inclining the new object creation is not?
This requires more attention while reading and debugging.
Cheers,
Michał Marcin Brzuchalski
