Godot 4.0 setget changed

[bitwes]

setget is something new in Godot 4.0. I think I rather like the new way.

https://godotengine.org/qa/114682/godot-4-setget-with-export

[bitwes]

only 132 instances of setget in the project, shouldn't be too much trouble.

[bitwes]

The changes from the default converter caused a bunch of recursion. I had to change the var with the set and get to not have an _ and then add an _ var:

var _add_children_to = self
var add_children_to = self :
	get:
		return get_add_children_to()
	set(val):
		set_add_children_to(val)

func get_add_children_to():
	return _add_children_to

func set_add_children_to(val):
	_add_children_to = val

[bitwes]

The new setters and getters are named @<property>_setter, @<property>_getter

print(inst.has_method('@has_setter_setter'))
print(inst.has_method('@has_getter_getter'))

[bitwes]

assert_set_get

• The assert no longer needs to verify that the methods were called.
• The assert no longer needs setter and getter method name parameters.
• The assert will verify that the @ methods exist on the object.
• add assert_set(obj, prop, set_value, get_value) for cases when set should not set the value to the same value passed to set. The message should be something like "Expected <prop_name> to be <get_value> when set to <set_value>".
• add assert_readonly which will verify that you cannot set a property. According to what I have read, if only get is defined then the property should be "read only". In practice this does not seem to be true. It's also not clear if an error will be generated if you try to set a readonly property. This method might just be asserting the @*_setter method does not exist, or it might have to try and set/get the value.
• add assert_setonly? I don't think this makes sense. A "set only" property should just be a method, not a property. I'd love to hear a good reason for this though.

Backing variable

As of now, there is no way to set the value of a variable with a set method without going through the setter. In order to be able to set the value internally without going through set you must make a backing variable (see _add_children_to above). There might be some value in being able to assert that property has a backing variable and it is being used by the set and get methods. This kinda feels like you are testing private functionality though, which isn't a good idea in general.

assert_accessors

It might be good to deprecate assert_accessors. I don't think they should be removed in the initial release as it will make porting code a lot easier. With the new set/get approach, even if there is a backing method it doesn't make sense to assert the name, or that they are used. There is also a chance that people will prefer the 3.x approach longterm. If that is the case then assert_accessors should be un-deprecated.

Deprecating the old way means that GUT has to do away with accessors and use the new way, which it probably should anyway.

[bitwes]

This has been addressed and all related README is now in the GODOT_4_README.