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

[Developers] Improve Consistency of Native_OnX, BP_OnX, and OnX Naming Conventions #50

Open
GuyPaddock opened this issue Aug 5, 2023 · 0 comments
Labels
enhancement New feature or request tech debt

Comments

@GuyPaddock
Copy link
Contributor

As a Developer, I'd like it if there was more consistency and/or documentation around when methods in the framework are named Native_OnX, BP_OnX, or OnX so that I know what to expect when I call these methods and can adhere to the convention in newer code.

Background Information

  • I believe these prefixes were adopted to avoid clashing with delegate events named OnX (e.g., OnCharacterAdded). This may no longer be necessary now that we have implemented the event emitter pattern for delegates, since the delegate properties now live in separate concrete UClasses.
  • Native_OnX (e.g., Native_OnCharacterAdded) is always used for the native implementation of an event, while BP_OnX (e.g., BP_OnCharacterAdded) is always used for a BlueprintImplementable or BlueprintNative event.
  • Given the above, I believe that in C++ code, native components tend to notify each other via Native_OnX calls that then dispatch calls to the BP_OnX variant.
@GuyPaddock GuyPaddock added enhancement New feature or request tech debt labels Aug 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request tech debt
Projects
None yet
Development

No branches or pull requests

1 participant