Re: instanceof survives non-object variables, but crashes on non-object constants.

I prefer the inconsistency between $x instanceof \stdClass and `1 instanceof \stdClass, than adding a warning (or throwing) to $x instanceof \stdClass when $x = 1`. I think 1 instanceof \stdClass === false would be reasonable. 1. PHP has no means of locking a variable to a type (i.e. the variable could be reassigned to a scalar at any point), so lack of an implicit is_object check in instanceof would basically move to require an explicit one in many cases it is used, if you want to be *sure* a warning won't be thrown that is (baring in mind just using the variable earlier might change its type non-visibly, since we don't have explicit caller opt-in to pass-by-reference). This to say that IMO $x instanceof stdClass when $x = 1 perhaps shouldn't be considered broken usage because it is useful for it to perform this check. Also consider that is_object($x) === false implies $x is not an instance of any object (and in-particular not of the object you might ask about with instanceof), so there is no reason instanceof wouldn't be able to do this check. There is also a certain amount of irony about making a type-checking operator start complaining when you give it the wrong type ;-) 2. There is already precedent for variables to act differently than literals, and even constants in PHP when used in object operators, for example ``` $x = new \stdClass; const y = 'stdClass'; $y = y; var_dump($x instanceof $x); var_dump($x instanceof $y); var_dump($x instanceof y); var_dump($x instanceof 'stdClass'); var_dump($x instanceof new \stdClass); var_dump($x instanceof (new \stdClass)); ``` where the three lines return false, the third as (the const isn't looked at, and no warning is thrown when checking against non-existent y class). The last three lines throw errors. Point here is that, "should variables be treated like their literal values?" is perhaps a bigger question, to which the answer at present seems to be "no" of object operators. I'm not opposed to moving towards constancy, but I think there being inconsistency isn't worth throwing in $x instanceof \stdClass when `$x = 1` (since inconsistency between variables and their values shouldn't be unexpected when using object operators). --- @Kalle > We should just add a warning to the first example, it seems like an oversight that it was left silent & > That is fine for code that is broken in the first place. Similarly we added a warning some years back about array to string conversions. As a data-point, usage with non-objects is documented behaviour http://php.net/manual/en/language.operators.type.php#example-115 so would this be spec change to say this is incorrect, as opposed to being a bugfix? Kind regards, Aidan On 9 December 2017 at 06:28, Andreas Hennings <andreas@dqxtech.net> wrote: > The following (https://3v4l.org/A2Tp6) is ok, it simply returns false: > > $x = 1; > $x instanceof \stdClass; > > > The following (https://3v4l.org/IdSBu) gives a fatal error: > > 1 instanceof \stdclass; > > t think this behavior is inconsistent, and we should consider changing it. > > There are two options, but only one is BC. > > - Let 1 instanceof \stdClass return false, instead of crashing. -> seems BC > - Let $x instanceof \stdClass crash, if $x is not an object. -> BC break. > > So it seems the first would the option we should take. > This is also what hhvm does, according to > https://3v4l.org/IdSBu. >