Godot: Implicit methods

[ghost]

_init() is implicitly called with new().

In the same way:

print(my_object) # could implicitly call a function my_object.to_string()
value in my_object # my_object.contains(value)
my_object == value # my_object.equals(value)
my_object[index] # my_object.get_item(index)
# etc etc

Like in Python
It's always fun to use. :)

[bojidar-bg]

Sounds interesting for other operators as well (+, -, *, /). I'm not sure we should allow users to override == though, since it is pretty useful for checking if two objects are the very same instance.

[neikeq]

Maybe adding an is keyword for instance comparison and allow overriding ==. I think that's how it works in Python:

is will return True if two variables point to the same object, == if the objects referred to by the variables are equal.
· http://stackoverflow.com/questions/132988/is-there-a-difference-between-and-is-in-python

[bojidar-bg]

Or we could just add === :stuck_out_tongue_winking_eye: (no really, don't)

[neikeq]

Also remember the x in y operator is used to check if the object y contains the variable by name x, if x is a String. If x is something different, the code calls getvar which seems unimplemented.

EDIT: Although I guess if a class overrides in, it's because it wants to hide that.

[neikeq]

Correct me if I am wrong but I think you can already override _iter_init, _iter_next and _iter_get.

[vnen]

Correct me if I am wrong but I think you can already override _iter_init, _iter_next and _iter_get.

This is true about for loops. But if your custom type implements a collection, the in operator can't be used to check if an item is inside it.

[neikeq]

I would like to discuss a bit on how this should be done (supposing we are going to implement it):
IMO Script should provide a virtual method called has_operator_override(Operator), and Variant::evaluate would check it before calling the overridden method. This way the Script implementation could cache the result to avoid slowing operators.
This would only need to be used for operators that already have a built-in behaviour for Object, like comparison operators, but can be ignored for operators like * and /.
Also the method call should be done with another virtual method, like call_operator(Operator, value, r_ret, r_valid). This way, GDScript could call __add__ (or whatever) and other languages could call their own method (e.g: op_Addition in case of C#).

BTW, this most likely cannot be done before 3.0 due to compatibility breakage.

[SleepProgger]

Just another 1+ for magic functions.
__str__ would be really nice for debugging.
I'd be more interested in _get being able to be used for everything not just strings tho.
The optimum imo would be _get and _get_index so ones wouldn't need to check the type for simple index stuff.

[bojidar-bg]

What about this in GDScript:

func _+(other):
  return get_script().new(self.number + other.number)
# .. - * /
func get_[](index):
  return bool((self.number >> index) % 2)
func set_[](index, value):
  self.number = self.number & (1 << index)
func _str():
  return str(self.number)
func _in(index):
  return self[index]

[Anutrix]

I think to_string works now.
The following works:

func _to_string()->String:
    return "Custom message when printed"

Because of https://github.com/godotengine/godot/pull/27886 (GDScript) and https://github.com/godotengine/godot/pull/29140 (C#).

[KoBeWi]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!