One of my favorite things about GDscript is the "onready" keyword, as it makes code much easier to read. It is primarily used for get_node, but also has other general uses.
Now obviously we cannot completely replicate onready in C# due to it being a typed language, but it would be nice to use at least part of it. Thus I request the GetNode attribute where you pass a NodePath into it as a parameter. This will generate code in the _Ready() method on compile depending on the field you use the attribute on.
Honestly this looks like a dirty workaround. :/
@groud Not really? Code injection is the bread and butter of some frameworks, such as Spring for example.
I was thinking of something like this for onready:
C#
[OnReady(() => GetNode("MyNode"))]
Node MyNode;
I've been working on such features in my project, and there's another one from the _Discord_ channel who has made something very similar.
I'm not too sure if we can all agree on a way to do it properly, as each of our projects has a slightly different style and scope from each other.
As such, I'd rather see #15548 or #15434 fixed first, so we can keep on experimenting our respective approaches and users can choose among them according to their individual requirements and preferences.
And if one of such project gains enough momentum, then probably we can join our efforts to create a _de facto_ DI framework based on that project, and maybe even integrate it into Godot itself.
But until then, I'd prefer Godot to be as flexible and extendible as possible to allow building many different injection frameworks on top of it, rather than having any specific implementation of such a feature provided by default.
Agreed with @mysticfall, I'd look into StructureMap or some other kind of DI layer before introducing some DI attributes into Godot.
@neikeq I don't think that would compile. Attributes only support constant arguments.
That's a shame :(
You can sort of achieve this by defining your own attribute. Like this one I've defined in my project: https://github.com/insraq/shotcaller/blob/master/NodeAttribute.cs
And then you can add an extension method to Node that wires the node: https://github.com/insraq/shotcaller/blob/master/Extensions.cs#L36
Then you should be able to write [Node("./Sprite")] private Sprite sprite; in your C#. But you have to call this.WireNodes(); in your _Ready: https://github.com/insraq/shotcaller/blob/master/Char.cs#L15
@neikeq What's the status on this issue? Was this fixed by #17720?
No, this is not implemented yet. #17720 is not related to this.
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!
Most helpful comment
I've been working on such features in my project, and there's another one from the _Discord_ channel who has made something very similar.
I'm not too sure if we can all agree on a way to do it properly, as each of our projects has a slightly different style and scope from each other.
As such, I'd rather see #15548 or #15434 fixed first, so we can keep on experimenting our respective approaches and users can choose among them according to their individual requirements and preferences.
And if one of such project gains enough momentum, then probably we can join our efforts to create a _de facto_ DI framework based on that project, and maybe even integrate it into Godot itself.
But until then, I'd prefer Godot to be as flexible and extendible as possible to allow building many different injection frameworks on top of it, rather than having any specific implementation of such a feature provided by default.