Refactor SetConstant to use a lookup table

[RealRanger]

The current implementation of ProfileStore.SetConstant relies on a long if/else chain to assign values. While it works, this approach:

• Is verbose and harder to maintain
• Increases the risk of typos

Solution

Refactored ProfileStore.SetConstant to use a private lookup table (_constantSetters) scoped in ProfileStore.

• Each constant name maps to a setter function that updates the corresponding constant.
• The rest of the codebase still used the same global constants; no breaking changes.
• New constants only require one new line in the lookup table.

Benefits

• Cleaner, more maintainable code
• Reduced risk of errors when expanding or changing the constants set

[Coffilhg]

That makes sense. You might also make setters perfectly safe, e.g. ProfileStore.SetConstant("AUTO_SAVE_PERIOD") would reset the value to default, like you could make the setter callback be:

AUTO_SAVE_PERIOD = function(v)
  if type(v) ~= `number` then
    warn(`[{script.Name}]: SetConstant "AUTO_SAVE_PERIOD" ~> A number expected, got {type(v)}; Resetting to default value of 300`)
    AUTO_SAVE_PERIOD = 300
    return
  end
  AUTO_SAVE_PERIOD = v
end

[RealRanger]

That makes sense. You might also make setters perfectly safe, e.g. ProfileStore.SetConstant("AUTO_SAVE_PERIOD") would reset the value to default, like you could make the setter callback be:

AUTO_SAVE_PERIOD = function(v)
  if type(v) ~= `number` then
    warn(`[{script.Name}]: SetConstant "AUTO_SAVE_PERIOD" ~> A number expected, got {type(v)}; Resetting to default value of 300`)
    AUTO_SAVE_PERIOD = 300
    return
  end
  AUTO_SAVE_PERIOD = v
end

Good idea; I’ve updated the setters to reflect this suggestion. Each one goes through a SafeSet utility, which enforces the type check and returns either the valid number or the default. That means even if someone bypasses SetConstant and calls a setter directly, it still goes through SafeSet and can’t corrupt the constant.