Not to beat a dead horse, but... what's the rationale, again, for throwing an exception after boot? Is there a real danger to some or all RulesSeqs being mutable after boot? If some, then those rules should selectively be protected. Even if they're all dangerous, there are better (i.e., type safe) ways of protecting RulesSeqs from mutation than just throwing an exception.
Nit-pick: why is 'toList' (which just returns 'rules') defined as private[http] when 'rules' itself is public? Also, if RulesSeq are always made up of either Functions or PartialFunctions, maybe we should enforce that at a type level, and the helper methods on Seqs of PFs that now exist in the NamedPF object can be put in the RulesSeq object. --j On Sat, Dec 13, 2008 at 2:31 PM, Marius <marius.dan...@gmail.com> wrote: > > All, > > I committed a bunch of changes in LiftRules. In a previous thread > Jorge suggested the abstraction of LiftRules variables. Lists of > functions are now abstracted by RulesSeq trait, which contains prepend > and append functions. Note that if you're calling prepend/append > functions after boot they will throw an exception. If there are > compelling reasons not to do this please let us know. This is just a > mechanism to enforce the use of these functions on startup. > > Br's, > Marius > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
