> While I understand the proposed feature is opt-int it introduces more magic
> that can be solved using more verbose and IMO cleaner solutions.
Understood and appreciate the position.
> This is somehow confusing, why is the $response storing object ref is ok
> while inclining the new object creation is not?
Not quite following, apologies.
Adding a different use case.
Allow for fully-specified custom collections; array being the compound type
that can resolve to false/empty based on count.
$array = [];
(bool) $array; // false
empty($array); // true
if ($array) {
// handle not empty
}
// handle empty
$array = [1, 2, 3];
(bool) $array; // true
empty($array); // false
if ($array) {
// handle not empty
}
// handle empty
Current state of PHP re custom collections (exclamation marks - ! - represent
difference compared to native array):
class MyCollection implements ArrayAccess, Iterator, Countable {}
$collection = new MyCollection([]);
(bool) $collection; // true - ! - because instance exists, regardless of
collection content
empty($collection); // false - ! - same reason as previous
if ($collection) {
// ! - handle empty and not empty
}
// ! - unreachable
$collection = new MyCollection([1, 2, 3]);
(bool) $collection; // true - because instance exists, regardless of collection
content
empty($collection); // false - same as previous
if ($collection) {
// ! - handle empty and not empty
}
// ! - unreachable
With RFC:
class MyCollection implements ArrayAccess, Iterator, Countable, Falsifiable
{
public function __toBool(): bool
{
return $this->count() > 0;
}
}
$collection = new MyCollection([]);
(bool) $collection; // false - because collection count === 0 - close to the
previous comment re single value under inspection
empty($colleciton); // true - same as previous
if ($collection) {
// handle not empty
}
// handle empty
$collection = new MyCollection([1, 2, 3]);
(bool) $collection; // true - because collection count > 0
empty($colleciton); // false - same as previous
if ($collection) {
// handle not empty
}
// handle empty
Alternative approaches for custom collection use case:
1. Modify Countable (most likely, if using alternative) to include empty() and
bool() methods.
Might feel more palatable despite not strictly limiting scope to the custom
collection use case.
Any class with Countable, for example, would also be able to resolve to false
or empty using SPL functions - including use in IF.
Allows for explicit (“verbose"), direct call of both methods by user should
they choose:
$collection->empty()
$collection->bool()
Instead of $collection->__toBool() OR something like $collection->__isEmpty()
Known drawback to using Countable would be in a possible future where there is
a separation between 0, false, and empty when it comes to type juggling in PHP.
Whereas using a Falsifiable interface leaves a simpler path of an Emptiness
interface; again, should the three be separated in the future.
2. Or, modify ArrayAccess to include the empty() and bool() methods.
This would restrict the behavior more toward the custom collection concept.
However, would lean more toward Countable due to the equivalence in PHP type
juggling and Countable using an integer: 0 == false == empty
Otherwise, similar to alternative #1.
3. Or, modify Iterator to include the empty() and bool() methods (or possibly
leverage the valid() method that already exists?); otherwise, similar to
alternative #2.
Cheers,
Josh
> On Nov 4, 2022, at 1:37 AM, Michał Marcin Brzuchalski
> <michal.brzuchal...@gmail.com> wrote:
>
>>
>> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
