-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
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
C#: Generate strongly-typed method to raise signal events and fix event accessibility #68233
Conversation
In Godot there's kinda the opposite convention: names of the methods subscribed (connected) to the event (signal) by default start with the
Makes more sense to me. I'd guess you've already considered many different options but do you think it would be possible to avoid incorporating |
That's true but we already prioritize .NET conventions over Godot conventions in other areas (e.g.: collections). You are probably right though that most users would be more familiar with Godot conventions in this case but I would love to gather more opinions on this before making a decision, that said I don't feel strongly either way about this.
In C# generic arguments are types and the name of the event is a string so this is not possible. Defining a method for each event follows the .NET guidelines, and since the methods are virtual it also allows you to customize how the event is raised in case the derived class needs it. Also, keep in mind the |
There's a conflict between the official .NET convention and the way Godot names callbacks (including the C# docs). I agree it's better to follow the .NET convention for the naming, but we need to think what to do about callbacks. NOTE: This PR doesn't include the generated native types, which would benefit from this as well. |
I first thought that you could override methods like for example |
29b035d
to
470af44
Compare
Isn't that up to the user to choose? Since they are the ones implementing those methods they are free to call them however they prefer. I guess my preference would be to name those methods after what they do and not after the signal that invokes them. For example, let's say you have a signal named event Action PlayerDied;
PlayerDied += ShowGameOverScreen; That way the code reads: |
194a094
to
c36e7dc
Compare
I meant we should think what to do about callbacks in the Godot documentation. Many examples use the We can't apply this change before first addressing that. |
In that particular example we could call the method |
That won't work for the connections' dialog, which generates a signal name automatically. Granted, this dialog doesn't generate pascal case names for C# yet, but ideally that should change. Additionally, I don't think it's a good idea to ask doc writers to think about such names. That may discourage those who translate these examples to C#. We need to come with a generic convention based only on the signal name (and class name if sender != receiver), even if we then recommend using a different convention.
I don't think we have much influence as to change such GDScript conventions. That being said, the signal naming convention in the docs is inconsistent. There are already other examples that use a naming convention like the one you suggest. The reason for needing a generic convention is still there, if only because it's needed for the connections' dialog. We are perfectly fine with following a different naming convention in C#, that's no problem. Ideas for a generic callback naming convention: |
To be honest I totally forgot about that dialog but yeah now that you mention it I can see the need for it.
I like |
a56e5bc
to
81c6fe6
Compare
Interested to hear updates on this discussion. I can see that the @godotengine/dotnet was assigned as a reviewer - does that mean that the feature is waiting for it's final approval before the release? Or is there more work planned? |
@raulsntos, is there a way for me to help to get this merged? Do you know what needs to be done? |
This PR needs to be reviewed by the @godotengine/dotnet team. Users can review it too and it's appreciated. There were previous concerns mentioned about the name of the emit method that conflicts with the name usually given by Godot to signal callbacks (#68233 (comment)). I suggest to change the callbacks names1 to something like The source generator changes can be tested without merging this PR, just copy the source generator code. It won't generate emit methods for native Godot types (e.g.: Footnotes
|
It's about invocation, right? Registering callbacks is up to the user, just like you said in the discussion above, where methods possibly prefixed with Wouldn't it be better to just name it |
I think there might've been a misunderstanding, with callback I'm referring to the methods that are subscribed and called when the event is raised. I'm suggesting to rename the callback name, not the name of the method that emits the signal. public class EventEmitter
{
public event Action? MyEvent;
// This is the method that raises the event.
protected virtual void OnMyEvent()
{
MyEvent?.Invoke();
}
}
public class EventReceiver
{
// This is the method that will be invoked when the event is raised.
// Godot currently uses the naming convention `On{SignalName}`
// which conflicts with the name of the method that raises the event.
public void MyEventCallback() { }
}
var emitter = new EventEmitter();
var receiver = new EventReceiver();
emitter.MyEvent += receiver.MyEventCallback; The name of the method that raises the event must be
|
Does this address godotengine/godot-proposals#7891 fully? If so it could be added to the OP. |
That proposal is about adding an analyzer for the I think if we merge this PR we probably wouldn't need the analyzer and just tell users to use the generated methods instead. So in that sense this PR would address the proposal, but there's no reason why we can't have both. The analyzer can be implemented externally though, so even if we don't implement it, users can create their own library and share it in NuGet.org. |
Fully agree with this. As non-expert game dev, there are quite a few use cases where one may want to be more explicit about what the subscribed methods are instead of enforcing to type a unique generic 'SignalNameCallback'. |
81c6fe6
to
4b81107
Compare
235e4a4
to
e00df4e
Compare
e00df4e
to
da37998
Compare
Thanks! |
Nevermind. |
public
it resulted in a compiler error because the delegate had less accessibility than the generated event which was always generated aspublic
, with this PR the event is generated with the same accessibility that the delegate was declared with.On{EventName}
method to raise signal eventsEmit{EventName}
if that's preferred.protected virtual
unless the class is sealed in which case it'sprivate
, this follows the .NET event guidelines.EmitSignal
.Sample: