Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for getting interfaces in OnReadyGet #30

Closed
Atlinx opened this issue Mar 17, 2022 · 2 comments
Closed

Add support for getting interfaces in OnReadyGet #30

Atlinx opened this issue Mar 17, 2022 · 2 comments

Comments

@Atlinx
Copy link

Atlinx commented Mar 17, 2022

It would be useful if we could use OnReadyGet to initialize an interface field with a reference node. Game engines like Unity include this feature in their GetComponent<T>() function.

@31
Copy link
Owner

31 commented Mar 18, 2022

Interesting... yeah, it would make sense to allow this, and it's a pretty simple change. GetNode<T> already allows this, I only need to tweak the generator to allow it rather than emit a compile error. I'll do it.


A potential issue is that [OnReadyGet] handles both nodes and resources, and currently it uses the type to determine which one it needs to fetch. The code behind the scenes is very different to handle each one. (GetNode vs. GD.Load, [Export] NodePath vs. [Export] <resourcetype>, and more fiddly internals.)

For example, it's impossible to tell whether IDoThings is attached to a resource or a node type:

public interface IDoThings { }
public class MyNode : Sprite, IDoThings { }
public class MyResource : Resource, IDoThings { }

public partial class Finder : Node {
  [OnReadyGet] private IDoThings _doer;
}

That said... I think it's safe for [OnReadyGet] to assume that an interface means it's a node. This is already a fairly niche scenario, but I think it would be way more niche to get a resource via an interface type. With how poorly (IMO) custom resource types work in Godot Mono right now, I think it's unlikely anyone will run into this limitation.

If someone does run into the limitation caused by the assumption, there are ways out. The easiest would be to add a bool arg onto the attribute that indicates the target should be a resource.

So, I think it's fine to relax this requirement and make this assumption.

@31
Copy link
Owner

31 commented Mar 18, 2022

I've released 1.1.3 that includes this change, let me know if it doesn't end up working for you! Thanks for the suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants