Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable
Thank you all for the engagement so far. (Note: All scalar types and one compound type can be cast as true or false natively - of the scalar and compound types, callable and object are the only two with no, native false representation.) > Have you tried not initializing invalid objects? This could help you. Also > that sounds more logical to me as I don't see any reasons to initialize > invalid objects if it's a matter of simple validation instead. I've tried valid objects (multiple approaches) - and I’m using the term valid loosely because the instances are not, technically, invalid in the strictest sense. I’m using “valid” and “invalid” as method names in the implementation because I don’t have a better word to describe the concept; still looking. If you'd like to hear more, please let me know and I can detail out other approaches, which are pretty standard. I only used it as an example of what would be possible and trying to illustrate using a real world example of the problem-space. With that said, the RFC isn’t meant to directly solve an implementation issue that can’t be solved any other way; it’s more syntax, style, and consistency (see note above). Similar to: function x(?SomeType $arg): ?SomeOtherType Instead of: function x(SomeType|null $arg): SomeType|null Both are the same thing under the hood. In that same spirit, totally opt-in - not required to use or you can get there some other way - similar to Marco’s comment around __toString. For example, I actively avoid null and don’t use most null-related things available in PHP and tend to wrap objects, methods, and functions that might return null…but, if you’re into null, don’t let me stop you. :) (I also tend to wrap objects, methods, and functions that return bool and some other type to put them in a context where I get one or the other, but not either-or - file_put_contents, for example…big fan of single return types.) > The one situation in which I can think of where an object might legitimately > have a falsey bool casting is if it represents a single value I see that, though I don’t necessarily agree. To use similar language, the object could represent a single, complex concept (especially through composition) - not just a single value. A car without a blinker is still a car and usable for most things it was designed for - and there could be a fallback for the missing blinker; valid instance with a non-blocking deficiency: https://www.dmv.org/how-to-guides/hand-signals-guide.php >>> P.S. I don't see it feasible to have objects that evaluate false in logical >>> expressions. I’m interested in more detail on this. Feasible as in not possible to do easily? Not possible in general? Or, something else? > For better or for worse (IMHO, for worse), `SimpleXMLElement` instances > representing attributeless empty elements are already falsy, so yes, it is > absolutely feasible. Interesting use case. Haven’t used SimpleXMLElement enough to comment. Interested to hear more. > This is absolutely terrifying. Not sure if this is referring to the SimpleXMLElement reference or beyond it. :) Cheers, Josh > On Nov 2, 2022, at 2:09 PM, Marco Pivetta wrote: > > On Wed, 2 Nov 2022 at 18:51, Claude Pache wrote: > >> >> >>> Le 2 nov. 2022 à 09:12, Michał Marcin Brzuchalski < >> michal.brzuchal...@gmail.com> a écrit : >>> >>> P.S. I don't see it feasible to have objects that evaluate false in >>> logical expressions. >> >> For better or for worse (IMHO, for worse), `SimpleXMLElement` instances >> representing attributeless empty elements are already falsy, so yes, it is >> absolutely feasible. >> >> —Claude > > > This is absolutely terrifying. > > Marco Pivetta > > https://twitter.com/Ocramius > > https://ocramius.github.io/
Re: [PHP-DEV] ReflectionType for iterable / PHP 8.2
FYI, it is also noted in the [UPGRADING][1] file: > - Core: > . The iterable type is now a built-in compile time alias for > array|Traversable. >Error messages relating to iterable will therefore now use > array|Traversable. >Type Reflection is preserved for single iterable (and ?iterable) to produce >a ReflectionNamedType with name iterable, however usage of iterable in >union types will be converted to array|Traversable [1]: https://github.com/php/php-src/blob/PHP-8.2/UPGRADING -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] ReflectionType for iterable / PHP 8.2
> > > That's a intentional behaviour change and related to this accepted PHP > 8.2 RFC: https://wiki.php.net/rfc/iterator_xyz_accept_array > > > > Smile, > > Juliette > > It is rather related the following RFC: > > https://wiki.php.net/rfc/dnf_types > > The change was discussed in this thread: > > https://externals.io/message/117577 > > —Claude Thanks to both of you, if this change is expected then I'll adjust my code accordingly. Benjamin
Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable
On Wed, Nov 2, 2022 at 1:12 AM Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > Hi Josh, > > Have you tried not initializing invalid objects? This could help you. > Also that sounds more logical to me as I don't see any reasons to > initialize invalid objects if it's a matter of simple validation instead. > > P.S. I don't see it feasible to have objects that evaluate false in > logical expressions. > > Cheers, > Michał Marcin Brzuchalski > The one situation in which I can think of where an object might legitimately have a falsey bool casting is if it represents a single value (that may have multiple properties associated with it, like units of measurement), and `if ($obj)` is really asking something like `if ($obj->castSingleValuePropertyToBool())`. For most of *these* situations, either `if ($obj->isEqual(0))` is equivalent, or `if ($obj == 0)` is equivalent if operator overloading was accepted. Jordan
Re: [PHP-DEV] ReflectionType for iterable / PHP 8.2
> Le 2 nov. 2022 à 19:54, Juliette Reinders Folmer
> a écrit :
>
> On 2-11-2022 18:46, Benjamin Morel wrote:
>> Hi internals,
>>
>> It just came to my attention that there is a change of behaviour between
>> PHP 8.1 and 8.2 in the way iterable is decomposed, or not, into
>> Traversable|array when reflected:
>>
>> ```
>> function foo(): iterable {}
>> function bar(): stdClass|iterable {}
>>
>> echo (new ReflectionFunction('foo'))->getReturnType(), PHP_EOL;
>> echo (new ReflectionFunction('bar'))->getReturnType(), PHP_EOL;
>> ```
>>
>> Output on PHP 8.1:
>>
>> ```
>> iterable
>> stdClass|iterable
>> ```
>>
>> Output on PHP 8.2:
>>
>> ```
>> iterable
>> stdClass|Traversable|array
>> ```
>>
>> Is this expected behaviour? Or should I file a bug? I'm particularly
>> surprised that it behaves this way on PHP 8.2 only in the presence of union
>> types.
>>
>> Thank you,
>> Benjamin
>>
> That's a intentional behaviour change and related to this accepted PHP 8.2
> RFC: https://wiki.php.net/rfc/iterator_xyz_accept_array
>
> Smile,
> Juliette
It is rather related the following RFC:
https://wiki.php.net/rfc/dnf_types
The change was discussed in this thread:
https://externals.io/message/117577
—Claude
Re: [PHP-DEV] ReflectionType for iterable / PHP 8.2
On 2-11-2022 18:46, Benjamin Morel wrote:
Hi internals,
It just came to my attention that there is a change of behaviour between
PHP 8.1 and 8.2 in the way iterable is decomposed, or not, into
Traversable|array when reflected:
```
function foo(): iterable {}
function bar(): stdClass|iterable {}
echo (new ReflectionFunction('foo'))->getReturnType(), PHP_EOL;
echo (new ReflectionFunction('bar'))->getReturnType(), PHP_EOL;
```
Output on PHP 8.1:
```
iterable
stdClass|iterable
```
Output on PHP 8.2:
```
iterable
stdClass|Traversable|array
```
Is this expected behaviour? Or should I file a bug? I'm particularly
surprised that it behaves this way on PHP 8.2 only in the presence of union
types.
Thank you,
Benjamin
That's a intentional behaviour change and related to this accepted PHP
8.2 RFC: https://wiki.php.net/rfc/iterator_xyz_accept_array
Smile,
Juliette
Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable
On Wed, 2 Nov 2022 at 18:51, Claude Pache wrote: > > > > Le 2 nov. 2022 à 09:12, Michał Marcin Brzuchalski < > michal.brzuchal...@gmail.com> a écrit : > > > > P.S. I don't see it feasible to have objects that evaluate false in > > logical expressions. > > For better or for worse (IMHO, for worse), `SimpleXMLElement` instances > representing attributeless empty elements are already falsy, so yes, it is > absolutely feasible. > > —Claude This is absolutely terrifying. Marco Pivetta https://twitter.com/Ocramius https://ocramius.github.io/
Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable
> Le 2 nov. 2022 à 09:12, Michał Marcin Brzuchalski > a écrit : > > P.S. I don't see it feasible to have objects that evaluate false in > logical expressions. For better or for worse (IMHO, for worse), `SimpleXMLElement` instances representing attributeless empty elements are already falsy, so yes, it is absolutely feasible. —Claude
[PHP-DEV] ReflectionType for iterable / PHP 8.2
Hi internals,
It just came to my attention that there is a change of behaviour between
PHP 8.1 and 8.2 in the way iterable is decomposed, or not, into
Traversable|array when reflected:
```
function foo(): iterable {}
function bar(): stdClass|iterable {}
echo (new ReflectionFunction('foo'))->getReturnType(), PHP_EOL;
echo (new ReflectionFunction('bar'))->getReturnType(), PHP_EOL;
```
Output on PHP 8.1:
```
iterable
stdClass|iterable
```
Output on PHP 8.2:
```
iterable
stdClass|Traversable|array
```
Is this expected behaviour? Or should I file a bug? I'm particularly
surprised that it behaves this way on PHP 8.2 only in the presence of union
types.
Thank you,
Benjamin
Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable
Hi Josh,
pon., 31 paź 2022 o 20:38 Josh Bruce napisał(a):
> Hello Interntals,
>
> Someone reached out to me outside of internals regarding the RFC I
> submitted on being able to declare objects falsifiable, so, I decided to
> update and re-enter the fray.
>
> I’ve updated the references section as many of the RFCs that were under
> discussion at the time have since been implemented.
>
> I still find myself in situations where having the capability would be
> beneficial. Specifically, I’m noticing with API responses where I want to
> pass the body received from a ResponseInterface the object can check
> itself. I currently use methods such as:
>
> ->isValid()
> ->isInvalid()
> ->toBool()
>
> And similar - the isValid and isInvalid() methods are just aliases of
> toBool(), which speaks to the ability for adopters to make their interfaces
> compatible without breaking changes in their code.
>
> In the case of a conditional - looks like this:
>
> $obj = Object::init($response);
> If ($obj->isValid()) {
> // do something with $obj
> }
>
> Or:
>
> If (
> $obj = Object::init($response) and
> $obj->isValid()
> ) {
> // do something with $obj
> }
>
> Would like to be able to do something like:
>
> If ($obj = Object::init($response)) {
> // do something with $obj
> }
>
> As of today, the last example is always true. You wouldn’t be able to
> create a guard clause for the negation:
>
> If (
> $obj = Object::init($response) and
> $obj === false
> ) {
> // handle invalid object, which could include something like
> $obj->failed()
> }
>
Have you tried not initializing invalid objects? This could help you.
Also that sounds more logical to me as I don't see any reasons to
initialize invalid objects if it's a matter of simple validation instead.
P.S. I don't see it feasible to have objects that evaluate false in
logical expressions.
Cheers,
Michał Marcin Brzuchalski
