feat(core): return SystemIDs in plugin abstract RegisterSystems#421
Conversation
📝 WalkthroughWalkthroughThe changes introduce a new Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Comment |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/engine/tests/engine/PluginTest.cpp (1)
5-5: Consider removing unused include.The
scheduler/Startup.hppinclude doesn't appear to be used in this test file. The tests only referenceEngine::Scheduler::Update, which is already available throughcore/Core.hpp.🧹 Proposed cleanup
#include "core/Core.hpp" #include "plugin/APlugin.hpp" -#include "scheduler/Startup.hpp"
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
src/engine/src/core/Core.hppsrc/engine/src/core/Core.inlsrc/engine/src/exception/MissingPluginError.hppsrc/engine/src/plugin/APlugin.hppsrc/engine/tests/engine/PluginTest.cpp
🧰 Additional context used
🧬 Code graph analysis (1)
src/engine/tests/engine/PluginTest.cpp (1)
src/engine/src/plugin/APlugin.hpp (2)
RegisterSystems(12-15)RegisterSystems(12-12)
🔇 Additional comments (8)
src/engine/src/core/Core.hpp (1)
272-279: LGTM! Clean API addition.The
GetPlugin<TPlugin>()method follows the established pattern of the existingHasPlugin()and resource management APIs. The documentation clearly specifies the exception behavior, and the signature is consistent with similar retrieval methods in the codebase.src/engine/src/exception/MissingPluginError.hpp (1)
1-11: LGTM! Proper exception design.The exception class follows standard C++ patterns by inheriting from
std::runtime_errorand using constructor inheritance. This provides a type-safe way to distinguish plugin-related errors from other runtime errors.src/engine/tests/engine/PluginTest.cpp (3)
80-88: LGTM! Test correctly verifies plugin retrieval.The test properly validates that:
- A plugin can be retrieved after being added
- The systemId is populated during the
Bind()call (which happens immediately inAddPlugins)
90-109: LGTM! Comprehensive test for the PR's main use case.This test effectively validates the primary motivation for the PR: retrieving systemIds to enable/disable specific systems. The test flow correctly:
- Registers the plugin and its system
- Runs systems once to verify execution
- Disables the system using the retrieved systemId
- Confirms the system no longer executes on subsequent runs
55-62: Verify the return type structure from RegisterSystems.The code assumes
RegisterSystemsreturns a tuple-like structure and usesstd::get<0>to extract the systemId. While this works if the underlying scheduler'sAddSystemsreturns a tuple, consider verifying this assumption holds across all scheduler types used in the codebase.#!/bin/bash # Description: Search for AddSystems method implementations in scheduler classes to verify return types # Find scheduler implementations and their AddSystems method signatures rg -n -A5 -B2 "AddSystems\s*\(" --type=cpp -g "*Scheduler*" -g "!test*"src/engine/src/plugin/APlugin.hpp (1)
12-14: LGTM! Proper forwarding of return value.The change from
voidtodecltype(auto)correctly forwards the return value fromRegisterSystem, enabling plugins to capture and expose system IDs. The use ofinlineis appropriate for this template method.This change is essential for the PR's goal of allowing users to retrieve and manage system IDs.
src/engine/src/core/Core.inl (2)
3-3: LGTM! Proper dependency inclusion.The include for
MissingPluginError.hppis correctly placed alongside the existing exception includes.
91-100: LGTM! Implementation follows established patterns.The
GetPluginimplementation correctly mirrors theGetResourcepattern:
- Type-safe lookup using
std::type_index- Throws descriptive exception if not found
- Returns reference via
static_cast(safe due to type_index guarantees)- Consistent formatting and error handling
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/engine/tests/engine/PluginTest.cpp (1)
64-65: Consider using a getter method instead of a public member variable.While the public
systemIdis acceptable for test code, production plugins should use a getter method (e.g.,GetSystemId()) to maintain encapsulation. This would follow C++ best practices and prevent unintended modifications to the stored ID.♻️ Proposed refactor using a getter method
- // For testing purposes, the systemId is exposed in public. Don't know if it's a good idea in production code. - FunctionUtils::FunctionID systemId; + FunctionUtils::FunctionID GetSystemId() const { return _systemId; } + + private: + FunctionUtils::FunctionID _systemId;Then update line 61:
- systemId = std::get<0>(systemIdTuple); + _systemId = std::get<0>(systemIdTuple);
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/engine/src/core/Core.inlsrc/engine/tests/engine/PluginTest.cpp
🚧 Files skipped from review as they are similar to previous changes (1)
- src/engine/src/core/Core.inl
🧰 Additional context used
🧬 Code graph analysis (1)
src/engine/tests/engine/PluginTest.cpp (1)
src/engine/src/plugin/APlugin.hpp (2)
RegisterSystems(12-15)RegisterSystems(12-12)
🔇 Additional comments (2)
src/engine/tests/engine/PluginTest.cpp (2)
55-62: LGTM! This correctly demonstrates the new SystemID capture feature.The
Bind()method properly demonstrates the PR's objective: capturing theFunctionIDreturned byRegisterSystemsso it can be stored and later used to enable/disable specific systems.
5-5: Remove the unnecessary include"scheduler/Startup.hpp".The
Engine::Scheduler::Updatetype is already available through the existing include chain:APlugin.hpp→Core.hpp→scheduler/Update.hpp. The newly added#include "scheduler/Startup.hpp"is redundant and does not provide the Update scheduler type. Unless the code explicitly usesEngine::Scheduler::Startup(which is not evident from the review context), this include should be removed.Likely an incorrect or invalid review comment.
|



Not related to any issues.
Small ECS feature yet very useful: while trying to disable a system, I encountered an issue where it was impossible to get the SystemID from a system registered with Plugin::Bind, because APlugin::RegisterSystems returned void.
Usually plugins should stay untouched by end users, and enabling/disabling something should be done with a resource.
But if we want to provide them a way to disable a specific system, it would be the following:
Summary by CodeRabbit
New Features
Refactor
Tests
✏️ Tip: You can customize this high-level summary in your review settings.