Seems like prime opportunity for an abstraction...
Why not make them (*gasp*) mutable data structures with prepend/append
methods?
--j
On Tue, Dec 9, 2008 at 1:35 PM, Marius [EMAIL PROTECTED] wrote:
Hi.
Unfortunatelly only some vars that are essentially Lists of something
are private and
Sounds good. I'll look into it
On Dec 9, 10:01 pm, David Pollak [EMAIL PROTECTED]
wrote:
And we should freeze the lists after Boot is finished. The permutation
methods should throw exceptions post-boot
On Dec 9, 2008 11:39 AM, Jorge Ortiz [EMAIL PROTECTED] wrote:
Seems like prime
Hm... I can think of situations where such mutations are useful after
Boot (app/prependSnippet comes to mind). Maybe they can be made immutable
(.toList) as necessary?
--j
On Tue, Dec 9, 2008 at 2:01 PM, David Pollak
[EMAIL PROTECTED]wrote:
And we should freeze the lists after Boot is
I'm not sure if this is the case ... if we want context dependent
Snippets then probably using loc snippets is the right place
How about something like:
abstract class RulesSeq[T] {
var rules : List[T] = Nil
private def safe_?(f : = Any) {
doneBoot match {
case false = f
I would use a ListBuffer as the underlying representation. I would call the
methods append and prepend (LiftRules.snippet.append,
LiftRules.dispatch.append, etc.). I would also make them immutable
as-needed. ListBuffer caches toList so that it's very efficient if you don't
append/prepend in
I agree with append/prepend naming. As far as ListBuffer goes I'm not
sure ... I mean you are correct about it, but these rules will be
done once in boot and I'm not sure who actually adds more then a few
items .. in practice.
At the end of the day I don;t mind using ListBuffer or List ...as I
I started to add a few RulesSeq ... looks pretty neat so far not to
mention that LiftRules is reducing its size. And these var can
actually be publicly exposed as val-s.
On Dec 9, 10:30 pm, Marius [EMAIL PROTECTED] wrote:
I agree with append/prepend naming. As far as ListBuffer goes I'm not
