Why 'is' is not ==

Help
,
1

Hi, do you know any reason why in gdscript is does not behave like ==?

extends Node

enum STATE{ON,OFF}
var state:STATE=STATE.OFF

func _input(event: InputEvent) -> void:
	if event is InputEventMouseMotion:
		print("this works")
	if event == InputEventMouseMotion:
		print("this doesnt")
	if state is STATE.OFF:
		print("this doesnt")
	if state == STATE.OFF:
		print("this works")
2

Hi,

is will check if the object is of a given type (can be extending a type or being a type).
== will compare the variable values, not their type.

Here, event is “of type” InputEventMouseMotion, but “is not equal” to the InputEventMouseMotion type, and state value “is equal to” STATE.OFF but is not “of type” STATE.OFF.

Not really sure what if state is STATE.OFF actually does as STATE.OFF is an enum value, which is not reaaaally a type, but you always want to check for enum equality using == anyway.

There are some good info here: GDScript reference — Godot Engine (stable) documentation in English

5 Likes
3

Thanks for the clear explain, however still wishing +1 on making is like ==

4

That would defeat the purpose of is and would make a lot of polymorphic operations a LOT more difficult to achieve, if not impossile. Sometimes you have to check if something is a specific type, and not just value. It would make no sense if == behaved exactly like is, and I do hope it’ll never happen. I suggest you read up on Object oriented programming, and you’ll see a lot of examples of why making them both behave the same way would be a bad idea.

4 Likes
5

Why? What does that even mean?
== tests for value equality.
is checks the type of an expression.
They do totally different things. Both very useful.

4 Likes
6

Where is this coming from? Do you know any languages where == and is are equivalent?

1 Like
7

I’m used to do my own type checking, void * is my friend, let’s me do whatever I want in C(++). Using enums is way faster than typechecking, and since I banged my head on walls for a morning trying to make a complex set of code working that hit the is is not == wall. If all derived objects had an enum instead of global lookups…

Thanks for all your comments, now is/== is burned in my brain, and hopefully not too many more walls to tear down ahead. Cheers

1 Like
8

In the end ‘is’ is just doing a cast against the object type and if it comes back as null or true.

Doesn’t make any sense to do that against an Enum value, which is just an int.

2 Likes