Arrays and get set with index

[donn-xx]

I find myself in this situation (in a custom Resource):

@export var mesh_sources : Array[Resource]:
	set(arr):
		mesh_sources = arr
	get:
		return mesh_sources

Now there's a nice gui in the Inspector. I add resources to that array, but I need to know as they are:

1. added. A.append() etc.
2. removed. A.remove_at(), A.pop_back(), etc.
3. retrieved by index. var foo = A[2]
4. changed at index. A[2] = 42

There's no built-in way, afaict, so I have to resort to playing games with tmp copies and diffing the old and new arrays. It's no fun.

What about something like:

@export var mesh_sources : Array[Resource]:
	set(arr):
		mesh_sources = arr
	get(action, index):
		match action:
			ARRAY_GET_INDEX:
				# I can do stuff in here
				hey_node(index)
			ARRAY_WRITE_AT_INDEX:
				print("Array changed at:", index)
			ARRAY_REMOVED_AT_INDEX:
				big_thing.array_changed.emit(index)
			ARRAY_ADDED_AT_INDEX:
				fancy_func_take_heed(index)
		return mesh_sources # as normal

That seems nice. It's not too radical a change and maybe get() can take zero or two params so as not to change code that just uses "get:"

Of course I don't know the underlying deets. Maybe a new keyword like "alter(action, index)"?

What do you think?

[lemilonkh]

Seems helpful for some custom resources. However I would say the notifications that the array is being changed should probably be handled by the set method instead of get? Since you're changing the value of the array.

Also, while I think a feature like this might be nice to include in the engine, you could probably get a lot of these methods by creating a subclass of Array in GDScript and overwriting the relevant methods, where you then emit a signal and call the original method (super).

So maybe just having the array signals implemented could be enough and would prevent having to implement this special case for the get/ set methods?

[donn-xx]

Good ideas! Not sure if one can extend Array. Hmm. Will try.

I chose get because that's the way it works right now. The 'set' is only called when the entire array is set, like var A := [1,2,3]. Other access to it (like append etc.) does not trigger it. Yeah, it's weird. OTOH, 'get' is called all the damn time. In order not to change old code it would make sense to hack only the get.

[donn-xx]

you could probably get a lot of these methods by creating a subclass of Array in GDScript ..

Seems not:

@tool
extends Array

Result:
res://test.gd:2 - Parse Error: Could not find base class "Array".

[lemilonkh]

Ok, so Array would need its class/ method exposed via ClassDB for this to work then. I think a custom Array subclass makes sense instead of another export hint to denote you would like to receive signals about array modifications.

So something like:
@export var properties: ModificationSignalArray = [1, 2, 3]

Otherwise it could be named NotifyingArray or SignalingArray, not sure which name works best for this.

But then it could emit signals like added(index: int, value: Variant), removed(index: int, value: Variant), ...

[donn-xx]

Sounds solid. I don't know what the devs will think. What would be less work: a new Array 'type' or hacking the get/set as in the op?

[Mickeon]

This is an interesting suggestion, but if not implemented carefully it would slow down writing and reading access to the Array considerably, even without making use of the feature. In fact, using ACTION constants and match is not exactly efficient, for how many times it could be executed.

func insert_at_array_index(idx, value)
func remove_at_array_index(idx)
func set_at_array_index(idx, value)
func get_at_array_index(idx)

These "middle-men" methods are the way to do this, currently, and that is completely fine. Godot's API already exposes many methods that behave like this. It is probably also expected for the array to not do any special meddling when it is being modified directly.

Problem is, there is no way to tell the Editor itself that these methods should be used when modifying the array. As is part of the suggestion, could it be some syntactic sugar exclusive to GDScript? A way to replace the previous methods, such that every access to the array calls them behind the surface. At worst, a special @export annotation for it?

[donn-xx]

Good points. Slowing things down would suck. I think the Editor should perhaps make some effort when it comes to controls (like the array control it has now) are being mutated. Perhaps some addon/plugin-specific signals?

OTOH, if this can be solved at a language-level, then code in-game can benefit too.

[Mickeon]

Speaking of addons, it's theoretically possible to create one that does this. It'd probably require creating your own EditorProperty to have it call the underlying methods. It would have to be added by overriding an EditorInspectorPlugin's _parse_property() to replace the normal array editor.

It's tricky and requires a decent amount of reading documentation, but not impossible. I have not seen any addon that tries something similar, however.

[donn-xx]

You, of course, jest :D I don't have enough lifetime to implement that beast!

[theraot]

I use a helper method with a signature like this: func update_array(current:Array, updated:Array, added:Array = [], removed:Array = []) -> void, it updates current to have the values of updated and populates added and removed with the items that were added and removed. I have used this for array properties where processing what changed is important. I mentioned it with other stuff in a rather rambling post I made here.

Since that I have moved to typed array versions of it.

Sadly, without generic methods, I have to keep a copy of this helper for each type of array I want to have. Thankfully, usually I don't need more than one type per module, which also helps me to not introduce a common dependency between them.

I didn't make a proposal for this because I didn't know if this would be well received, I made the mentioned post to try to find out. Yet, it didn't get much attention, probably because brevity eludes me.

[donn-xx]

A good proposal, I thought. Yes, it's a problem. I posted there.

[theraot]

@donn-xx I don't know if it is clear why I bring this up, so look, you could write code like this:

@export var mesh_sources : Array[Resource]:
	set(arr):
	        var added := []
	        var removed := []
	        update_array(mesh_sources, arr, added, removed)
	        for entry in added:
	            prints("added: " + entry)
	            
	        for entry in removed:
	            prints("removed: " + entry)	            

And what I'm arguing is that you shouldn't have to implement update_array in every addon/plugin/module that needs it, instead something like that should be in core.

[donn-xx]

Yeah, I see. I am probably doing a much worse job of your update_array func. I agree, this should be in core, hence my OP.

Your other points about shared blocks/libs/whatever of code between addons also makes sense. That's the paradox part. To bloat or not to bloat, that is the vexation! :D