[Lift] Re: LiftRules consolidation
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 prepend/append functions are exposed. I proposed to do this for ALL List variables. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: LiftRules consolidation
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 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. Unfortunatel... --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: LiftRules consolidation
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 finished. The permutation methods should throw exceptions post-boot On Dec 9, 2008 11:39 AM, Jorge Ortiz [EMAIL PROTECTED] wrote: 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. Unfortunatel... --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: LiftRules consolidation
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
case _ = throw new IllegalStateException(Can not modify after
boot.);
}
}
def prependRule(r: T) {
safe_? {
rules = r :: rules
}
}
def appendRule(r: T) {
safe_? {
rules = rules ::: List(r)
}
}
}
Br's,
marius
On Dec 9, 10:12 pm, Jorge Ortiz [EMAIL PROTECTED] wrote:
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 finished. The permutation
methods should throw exceptions post-boot
On Dec 9, 2008 11:39 AM, Jorge Ortiz [EMAIL PROTECTED] wrote:
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. Unfortunatel...
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: LiftRules consolidation
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 between calls to toList.
On Tue, Dec 9, 2008 at 2:20 PM, Marius [EMAIL PROTECTED] wrote:
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
case _ = throw new IllegalStateException(Can not modify after
boot.);
}
}
def prependRule(r: T) {
safe_? {
rules = r :: rules
}
}
def appendRule(r: T) {
safe_? {
rules = rules ::: List(r)
}
}
}
Br's,
marius
On Dec 9, 10:12 pm, Jorge Ortiz [EMAIL PROTECTED] wrote:
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 finished. The permutation
methods should throw exceptions post-boot
On Dec 9, 2008 11:39 AM, Jorge Ortiz [EMAIL PROTECTED] wrote:
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. Unfortunatel...
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: LiftRules consolidation
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
think in this specific context it has little consequence. If this
approach is fine with everyone I can start implementing it.
Br's,
Marius
On Dec 9, 10:25 pm, Jorge Ortiz [EMAIL PROTECTED] wrote:
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 between calls to toList.
On Tue, Dec 9, 2008 at 2:20 PM, Marius [EMAIL PROTECTED] wrote:
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
case _ = throw new IllegalStateException(Can not modify after
boot.);
}
}
def prependRule(r: T) {
safe_? {
rules = r :: rules
}
}
def appendRule(r: T) {
safe_? {
rules = rules ::: List(r)
}
}
}
Br's,
marius
On Dec 9, 10:12 pm, Jorge Ortiz [EMAIL PROTECTED] wrote:
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 finished. The permutation
methods should throw exceptions post-boot
On Dec 9, 2008 11:39 AM, Jorge Ortiz [EMAIL PROTECTED] wrote:
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. Unfortunatel...
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: LiftRules consolidation
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
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
think in this specific context it has little consequence. If this
approach is fine with everyone I can start implementing it.
Br's,
Marius
On Dec 9, 10:25 pm, Jorge Ortiz [EMAIL PROTECTED] wrote:
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 between calls to toList.
On Tue, Dec 9, 2008 at 2:20 PM, Marius [EMAIL PROTECTED] wrote:
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
case _ = throw new IllegalStateException(Can not modify after
boot.);
}
}
def prependRule(r: T) {
safe_? {
rules = r :: rules
}
}
def appendRule(r: T) {
safe_? {
rules = rules ::: List(r)
}
}
}
Br's,
marius
On Dec 9, 10:12 pm, Jorge Ortiz [EMAIL PROTECTED] wrote:
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 finished. The
permutation
methods should throw exceptions post-boot
On Dec 9, 2008 11:39 AM, Jorge Ortiz [EMAIL PROTECTED] wrote:
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. Unfortunatel...
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
