Change schedule labels to constructor types

[waynemwashuma]

Objective

Refactor schedule identification to use constructor-based schedule labels instead of string labels. Previously, schedules were identified using raw strings such as 'startup' and 'update' This introduces typed constructor-based schedule labels, improving schedule isolation, type safety, internal consistency and integration with the engine’s existing type identity system.

Solution

The scheduling system previously relied on string identifiers. This has several possible problems:

• string collisions across unrelated schedules
• weak type safety
• inconsistent identity handling compared to system groups/types
• fragile internal lookups
• harder refactoring and tooling support
• runtime ambiguity when labels changed

The engine already uses constructor/type-based identity extensively elsewhere through typeid(), but schedules remained string-based.

Why this approach

Alternative approaches considered:

• namespaced string constants
• symbols
• UUID-based schedule labels

Constructor-based labels integrate best with the existing ECS/type architecture because:

• schedules already behave like engine types
• type infrastructure already exists
• constructors provide readable names
• APIs become more self-documenting
• tooling/autocomplete improves significantly
• accidental collisions become much harder

This also creates consistency between:

• schedules
• system groups
• components
• resources
• assets

all of which already use constructor identity semantics.

Showcase

Before

scheduler.set(new Executable({
  label: 'update'
}))

scheduler.get('update')

After

class Update {}

scheduler.set(new Executable({
  label: Update
}))

scheduler.get(Update)

Migration guide

String schedule labels are no longer supported. All schedule registration and lookup now relies on constructor identity.

Checklist

• I have updated the documentation accordingly.
• I have added tests to cover my changes.