On Sun, Dec 14, 2008 at 9:28 AM, Marius <marius.dan...@gmail.com> wrote:
> > > > On Dec 14, 3:02 am, "Jorge Ortiz" <jorge.or...@gmail.com> wrote: > > 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. > > This was actually DPP's suggestion. I'm not sure why would someone > mutate them after boot but I'm totally opened if there is a strong > case for allowing that. I do not have strong feelings about this so > changing it would be trivial. Still I kind of like it this way. What > other ways of protecting mutations after boot are you referring? ... > something like ignore it and do nothing? Hmm, how about "locking" them by havign a paralell lazy val? val somePf : RuleSeq = Nil; lazy val runtimeSomePf = somePf.toList Then prepending/appending on the somePf AFTER runtimeSomePf has been dereferenced won't make a difference. (runtimeSomePf would be used by Lift internally if that isn't clear enough :) ) Or another, perhaps more suitable suggestion: make boot() have an InitializationContext parameter that's only available in the scope of boot, and then the problem should disappear? Cheers, Viktor > > > > > Nit-pick: why is 'toList' (which just returns 'rules') defined as > > private[http] when 'rules' itself is public? > > Why would you use toList in the lift app code? ...RulesSeq is mainly > about adding user functions to lift. If "rules" itself is public > doesn't necessary mean that it should not have its "private" logic. > > > > > 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. > > But what would be the benefit? .. except that it would simplify a bit > how Lift calls these PF's? > > ... to me distinguishing between functions and partial functions here > by using Either or even using different RulesSeq traits would not > bring much benefits ... but I hope I'm wrong. > > > > > > > --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 > > > -- Viktor Klang Senior Systems Analyst --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
