SystemManager (SMC 3.0) API specification

[alikindsys]

Here is the currently proposed SystemManager API specification

• Modify the current SMC structure to :

-- interface IStaticSystem
-- interface IClientSystem
++ abstract class BaseSystem 
++ abstract class ClientSystem : BaseSystem

• BaseSystem will expose SisbaseBot SisbaseInstance
• ClientSystem will expose DiscordClient Client

Getting a system in a command

class command : SisbaseCommandModule {
  public SystemType System = SisbaseInstance.Systems.Get<>();
}

[alikindsys]

DependsAttribute - #47/1

Adds a DependsAttribute to the spec of #47.

Reason

Add a way for making systems interdependent - #9

Modifications Required

• That would require a way to know which systems have attempted registering, like an UnloadedSystems hashset.

• SystemManager would also need a way to load each system recursively, based on the dependencies of each system.
  If a system has a [Depends], SystemManager will try to register the dependencies first, if said systems aren't registered yet,
  or haven't been attempted registry yet, adding said system onto UnloadedSystems in the case of a dependency missing.

• After some consideration, knowing the reason of why a system was unloaded is extremely helpful. An UnloadingReason data type could be added with Type and Reason Fields. Type would be an enum containing MANUAL_REQUEST, DEPENDENCY_MISSING, LOADING_ERROR (happens if IsEnabled is set to false on code, better name could be chosen), while the reason field would be a string containing, on the case of a dependency which dependency(ies) caused the system to be unloaded. That later could neatly be displayed via the systems.status command.

[alikindsys]

The 3.0 Spec is currently implemented. 47/1 - DependsAttribute extension will be postponed to a minor version after 2.0 release.