On Dec 14, 12:10 pm, "Viktor Klang" <viktor.kl...@gmail.com> wrote:
> 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
> :) )
Still we'd allow useless strong references on those lists.
>
> 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?
How would the problem disappear? ... I mean after boot people would
still be able to add their functions (from API perspective) and they
would be surprised that their functions are not called and yet lift
just allowed them to do that.
>
> 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
-~----------~----~----~----~------~----~------~--~---
