Think about reconceiving boot as a (LiftRules)=>LiftRules function

[Shadowfiend]

More thoughts in this ML thread.

Basic idea is that boot goes from being a no-arg function that does mutable setup, to being a function that takes an immutable LiftRules parameter and updates its values to a final immutable LiftRules that is returned and then installed as the final rules state. State mutability would be captured in things like FactoryMakers in this conception, while most values would simply be immutable.

The transition here would be interesting, and this may push this into being something we should do for a hypothetical Lift 4, potentially.

[Shadowfiend]

Another interesting thought here would be breaking down the large number of LiftRules settings into separate immutable classes, which in turn can get their own boot functions. That also involves the discussion of whether it would be a net good to break out LiftRules into multiple sub-things, though, and there's never been a clear consensus one way or the other.