Godot: Adding back support for deprecated API methods to ease transition to Godot 3.0

[Ranoller]

I know that change in scene files and API is necessary, but usually scripting system mantain old words for scripting compatibility. It´s ok that stetic-reasons recommend that get_pos() will be get_position(), but... Any reason for lost old expresion in scripting system?

This words change can fragment the valid gdscript code base-date in internet (people don´t actualize blogs, youtube tutorials, etc...). Is not posible to keep synonym expressions like "const" to new expression or something like that in the code base ( I don´t know c++ but something like: get_pos() -> get_position() in GDScript module is possible?). By the fact with this changes there will be GDscript 1.0 and GDscript 2.0, add words look ok, but lost words?. There is debate in this topic?

[RandomShaper]

API renames aren't actually a GDScript matter. It's actually the classes which have changed the naming of their members. And that affects any scripting language usable with Godot.

Regarding keywords and syntax, those would be indeed changes in GDScript itself. But to keep moving on, in 3.0 a lot of compatibility has been broken because it was a good opportunity. I wouldn't expect changes as big as those for a long time.

But I feel your pain about online resources. It's the same as when you are learning Angular (2.0+) and you have to carefullly filter out search results about AngularJS (1.x), which are different animals. Problematic but probably not avoidable.

[akien-mga]

We could add compatibility bindings for old method names, and make them issue a deprecating warning in the console so that people replace them. That's just a lot of code to add, and it also means that the autocompletion will be full of duplicates that may hinder the learning of new users.

If someone is ready to make a list of all method renamings (at least the ones that can be converted, not the ones that were obsoleted altogether), we could assess how much work it would be. Maybe we could add a way to bind methods to GDScript that won't make them appear in the autocompletion and will automatically trigger a deprecation warning when used.

I did it this way a few releases ago for some methods that were being renamed/removed: https://github.com/godotengine/godot/blob/afbb5261e660acf08dd62f698d353e95fc7fb6bb/scene/3d/spatial.cpp#L356-L360
But as you can see, one of the obvious drawbacks is that one or two major releases later the compatibility code is still there and unnecessarily bloating the source.

All in all, I think that a good documentation page with a list of all renamed methods/classes would be better than adding tons of compatibility bindings. It means a bit more manual conversion work, but it's not that bad to be honest.

[eon-s]

I'm in favour of documenting changes and let old things break, so the person who is trying to use an old tutorial can search for a new one or try to fix it instead.

[Ranoller]

Documenting is always the better option, and this changes don´t affect to current users (us) because we follow Godot develop. I see the problem in the new users, Godot have relatively tiny internet database, and this kind of changes can turn some resources obsolete, it´s important to remember the two main applications that are used to programming: Code editor and google, this changes affect the last aplication (Most important maybe?) and Godot need more and more users to become better. Probably this is an exageration, but is important to think in that for future changes. Mess the API with obsolete functions don´t help to the readability of the code, but standard syntax error menssage in console to the input methods deprecated, or set/get_pos(), or Arrays don´t help new users to jump to Godot. I like the console menssage: -Do you mean .......? it´s very helpfull, but i don´t know if it is a lot of work implement this to the deprecated methods.

I´m thinking in one of the best youtube tutorials to understand Godot, one of the Juan Linietsky youtube channel, "el tutorial del matamarcianos", is in spanish but if you follow the code you can understand the generic use of godot, he uses set_pos() function, and now this tutorial become obsolete, and is a pity because it´s real start- to end minigame...

[vnen]

I believe the old tutorials will become (partially) obsolete when Godot's evolution changes the workflow of some topics, not really because of changes in the name of methods. Just because now you do position = new_pos instead of set_pos(new_pos) doesn't mean that the whole tutorial is useless.

For instance, the removal of the Opacity property in favor of Modulate is a much bigger change and while we could add a deprecated set_opacity() function to access from code, it would still not show in the editor. This would throw off people following old tutorials and it's much harder to add deprecated properties in-editor, because if it's there, people won't stop using it ever.

I understand that this will be a problem for new users, but eventually the tutorials will be update and the new users asking "why this doesn't work" will simply receive the answer "it changed in Godot 3" and can move on. It's not ideal but already happened in the past and it has been a long time the last I heard someone asking "where is the Resources dock?".

In the end, it's just easier to document the changes than to add deprecated functions that'll have to be maintained and someone will have to remember to remove then in the future (which will likely bring complaints anyway).

[Sslaxx]

Could always do a bare-minimum implementation (with accompanying warnings about imminent deprecation and what the old-style is replaced with) for 3.0, and remove them in 3.1.

[neikeq]

EDIT: life is cruel

[reduz]

As discussion ended up a in a "better not", will close this. I'm against this, also. There's waaaay to much that broke in 3.0, not just the methods.