Renaming Node.get_index to Node.get_sibling_index

[minionprocyk]

It took me a while to figure out that godot even had a method of determining the node's sibling index in a tree. Namely because I searched everywhere for "sibling index".

I am proposing renaming get_index to get_sibling_index because it's more obvious, and it is also the same alias that Unity uses which may help lots of people transitioning into godot.

Unfortunately this is an obvious breakage of the api so would constitute a major version upgrade. Let me know what yall think!

[AThousandShips]

To me "sibling index" isn't clear, and it doesn't make sense to me to change the name just because another engine uses a particular naming

But for helping confusion we can add it as a keyword to the method and it'll be easier to find

[minionprocyk]

i think sibling index is rather verbose. maybe just get_sibling, i mean we have get_parent(), and get_child((int index) why not get_sibling(int index)???

edit: the proposal is not to change it because another engine does it different. The proposal is to change get_index because it's not clear at first glance that that method would do, nor to search for it when trying to find a node's sibling in the documentation, and it has an added benefit that other engines use a similar naming convention and will enable users of those engine to more easily adapt to godot

[AThousandShips]

What are you suggesting? To replace get_index with get_sibling? How is this relevant to the issue of get_index being confusing? I'm not sure what you are trying to suggest.

If by get_sibling(i) you mean just get_parent().get_child(i) that would be very confusing for a lot of people, to me the get_sibling method would return get_parent().get_child(get_index() + i), why would get_sibling(5) mean "get the 5th child of my parent" and not "get the child of parent 5 nodes after me"?

I'm not sure how we got here from the original topic

Also I'm just suggesting that we add a disambiguation entry to get_index like how Color has Colour to help searching, not to change or rename anything, just to avoid any confusion

Because renaming this method is not possible in 4.x, and there's little justification to do so especially as anyone already using the engine, or 3.x, would be confused, and adding a second method that just does the same isn't a good idea either

[timothyqiu]

I ran into the same issue a long time ago. But the other way around.

I did not know how other engine names this method. I tried searching for method like parent.get_child_index(this_node). I never thought it will use such a generic name ;)

[Mickeon]

Yeah, I would rather this method be called get_child_index. On a very nested inheriting class, the original meaning of get_index() is lost and vague, similar to how queue_redraw() was vaguely called update() in 3.x.

[tiloc]

I think sibling is a common term used in tree APIs, not just in Unity, but for instance also in several Java libraries. However it seems that practically all of them are based on iteration, rather than indices. Would it make sense to leave the existing one untouched, and add iteration-based ones which include sibling in their name? In Java I have seen methods on tree nodes with signatures like "get_prev_sibling" and "get_next_sibling".