[RFC][Discussion] Objects can be declared falsifiable View as Markdown

Since this topic fits like a glove, just dropping the "why I don't use
__toString()" argument here:
https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460085493

A falsifiable object is worse than __toString() in this context, IMO.

Marco Pivetta

https://twitter.com/Ocramius

https://ocramius.github.io/

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()
}

Cheers,
Josh

Hey Internals,

So, I received a message that said of the mail I should have received
from internals bounced; so, this is part test and part update.

I’ve started mapping out call paths in the project that brought this
concept to light.

The project, Shoop, never uses is_bool() - instead it always uses empty,
then reverses that for:

1. Booleans
2. Numbers
3. Arrays
4. Strings
5. stdClass or data-only classes
6. Json strings, which it treats as #5

I essentially get standard SPL behavior when I do this.

For the object definition I can define two interfaces:

1. Falsifiable
2. Emptiable

The checks go like this:

1. if the object implements Falsifiable: the __toBool method would be
   called and would return the result. (This check would be inside is_bool()
   and could use the empty() implementation)
2. if the object implements Emptiable: the __isempty method would be
   called and return the result. (This check would be inside empty())
3. else: standard output from is_bool() or empty() would be used when
   passing an instance to either of those SPL functions, depending on which
   the user is using.

Because the concepts of emptiness and falsiness are so tightly coupled,
I’m wondering if it would be better to implement both with this RFC??

Otherwise, Emptiable would be a future enhancement consideration.

I’d like to hear what the rest of Internals thinks.

Next for me: I’m going to finish solidifying the Shoop project and make
sure my other projects can use latest and then continue going through the
tutorials from Nikita and others on doing development Internals.

Cheers,
Josh

On Aug 30, 2020, at 9:32 AM, Josh Bruce &lt;josh@joshbruce.dev <mailto:
josh@joshbruce.dev>> wrote:

Hey Tyson,

This is great! Thank you so much, sincerely.

Still slow goings, which is fine, we have at least a year. lol

Static analyzers seem to be the biggest concern to date.

Haven’t been able to get one running locally - though I’ve only spent a
few minutes here and there; definitely on the list.

A use case for this sort of thing is also a concern or question. I came
across Pipeline from the PHP League and saw their interruptible processor
and was wondering if something like this would be helpful there - for
pipeline patterns in general:
https://github.com/thephpleague/pipeline/blob/master/src/InterruptibleProcessor.php

While working on another project, saw this line from the PHP
array_filter docs:

"If no callback is supplied, all entries of array equal to `FALSE` 

(see converting to boolean) will be removed."

I’m still field testing the latest iteration of my base project, but
wanted to put a working (non-internals) implementation out there (note this
covers emptiness and falseness for the purposes of the project):

Tests -
https://github.com/8fold/php-shoop/blob/master/tests/RfcObjectCanBeDeclaredFalsifiableTest.php

Interface -
https://github.com/8fold/php-shoop/blob/master/src/FilterContracts/Interfaces/Falsifiable.php

• for our purposes the efToBool would be __toBool

Default implementation -
https://github.com/8fold/php-shoop/blob/master/src/Shooped.php#L216

“Type system” implementation -
https://github.com/8fold/php-shoop/blob/master/src/Filter/TypeAsBoolean.php

Cheers,
Josh

On Aug 9, 2020, at 3:59 PM, tyson andre &lt;tysonandre775@hotmail.com
mailto:tysonandre775@hotmail.com> wrote:

Hi Josh,

I'd recommend looking at https://github.com/php/php-src/pull/5156
(linked to in your RFC's reference) when implementing this PR.
Additionally, I didn't see if this was brought up - PHP already has a
class which is falsifiable - SimpleXMLElement.

You can see the source of ext/simplexml/simplexml.c for _IS_BOOL

static int sxe_object_cast_ex(zend_object *readobj, zval *writeobj,

int type)

{
php_sxe_object *sxe;
xmlChar *contents = NULL;
xmlNodePtr node;
int rv;

sxe = php_sxe_fetch_object(readobj);

if (type == _IS_BOOL) {
        node = php_sxe_get_first_node(sxe, NULL);
        if (node) {
                ZVAL_TRUE(writeobj);
        } else {
                ZVAL_BOOL(writeobj, !sxe_prop_is_empty(readobj));
        }
        return SUCCESS;
}

static php_sxe_object* php_sxe_object_new(zend_class_entry *ce,
zend_function *fptr_count)
intern->zo.handlers = &sxe_object_handlers;
// ... elsewhere in ext/simplexml/simplexml.c
sxe_object_handlers.cast_object = sxe_object_cast;

The default handlers would be overridden, so this would probably need

to fall back to the original handlers for types other than bool.

Also, this might need to copy all of the handlers from the parent
class entry's zend_object_handlers,
to meet the expected behavior of other cast types and other magic
behaviors from SimpleXMLElement and other classes continuing to work.

From the perspective of static analysis, a few things to note:

• Static analyzers such as psalm/phan currently deliberately don't
  bother handling the possibility that object can be false even after it
  was checked for falsiness.
  There's hundreds of other things that could be implemented, and
  adding the special casing and performance overhead checking for FFI objects
  and SimpleXMLElement, subclasses of those is currently low priority
  compared to those things.

Code using SimpleXMLElement/FFI is generally limited to a few files
in practice.

Definitely possible for analyzers to support this for known base
classes, though, and the priority would increase if the RFC passed.

I am a maintainer of Phan.

• For BC reasons, internal data structures such as ArrayObject
  probably wouldn't get changed in any php release
  (e.g. could break code using falsiness check instead of null check).
  So this might lead to inconsistencies with newer extensions if half
  of the data structures treat emptiness as false and half don't.
• This feature may end up getting adopted in cases where it's
  convenient but turns out prone to accidental bugs and later is deprecated
  and removed.
  For example,
  https://stackoverflow.com/questions/25031236/if-elem-vs-elem-is-not-none
  was seen in python

(e.g. if (!$this->resultSetObject) { $this->resultSetObject = slow_db_operation(); }
would not behave the way people would previously expect for most
objects (executed repeatedly instead of once))

<?php
function test(SimpleXMLElement $e) {
   // False positive RedundantCondition in psalm
   if ($e) {
   }
}

And I don’t know of a way to add an interface to new stdClass() - but
thought this might be a valid use case:

stdClass isn't a final class. I assume they meant this

class EmptyStdClass extends stdClass implements Falsifiable {
   public function __toBool() { return false; }
}
function example(stdClass $s) {
   if (!$s) { throw new Exception("Previously impossible"); }
}

Thanks,

• Tyson
  --

To unsubscribe, visit: https://www.php.net/unsub.php

Hi Josh,

pon., 31 paź 2022 o 20:38 Josh Bruce josh@joshbruce.dev 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