Thanks again for the cool details. I now get it. Thanks. - Debasish
On Mar 4, 9:48 pm, David Pollak <[email protected]> wrote: > On Wed, Mar 4, 2009 at 8:26 AM, debasish <[email protected]> wrote: > > > David - > > > Thanks a lot for the clear explanation. > > > Just curious - do you think the previous implementation philosophy of > > controllers, sessions and pages as actors with state changes being > > done only through messages was a more FP oriented approach ? > > Actually, just the opposite. :-) > > Actors and OO are twin concepts. Actors provide state, data hiding and > messaging (sound like words that come from Smalltalk) in a world where > mutability is eschewed. It turns out that Actors have their roots in Scheme > and that Smalltalk has its roots in Scheme's Actor implementation (if you > need a reference, I'll dig it up.) > > Rarely is LiftSession state mutated directly. With the exception of > SessionVars, S (threadlocal state) holds a list of state mutations (new > functions that are bound to HTML elements). Having granular read operations > on LiftSession and application of state changes accumulated in S as part of > the completion of page rendering is about as close as I could get in Scala > to Haskell's state monads. > > > And that > > the actor model broke down since Session is inherently an abstraction > > that needs to be more stateful. > > The Session is an abstraction that is very, very complex and there's lots of > highly granular data that needs to be exposed during the processing of a > request. This granular data is better exposed on LiftSession than via > request/response messages or some proxy "thingy". > > Put another way, it depends on what you mean by "state". It would be > possible to pass a LiftSession around as an explicit parameter and return a > mutated LiftSession... making things feel more "functional", but this gets > back to the limitations of Scala vis Haskell's state monad. > > Put another way, LiftSession has very few public mutator methods. It's > mostly read-only. Is this "state" in the same way that a JavaBean is > stateful. Now that's a debate worth having (better line up James and > others.) :-) > > Thanks, > > David > > > > > > > Thanks. > > - Debasish > > > On Mar 4, 9:10 pm, David Pollak <[email protected]> wrote: > > > On Wed, Mar 4, 2009 at 7:59 AM, debasish <[email protected]> > > wrote: > > > > > Dear All - > > > > > I have had a look at Lift quite some time ago. I remember referring to > > > > this excellent post by David Pollak on the usage of actors in Lift > > > > (http://blog.lostlake.org/index.php?/archives/59-How-lift-uses-Scala- > > > > actors.html). Now that I am looking at the code base after quite some > > > > time, I find lots of changes in it. e.g. the above post refers to > > > > implementation of Session, Page, Controller etc. as Scala actors that > > > > nicely interacts in the Request / Response cycle of Lift. But the > > > > latest snapshot from Github indicates that the usage of actors in Lift > > > > is now different. Is there any document or pointer that describes the > > > > rationale of this change or explains the current usage of actors in > > > > request / response processing ? > > > > Howdy, > > > > As Lift evolved and I did performance analysis, I found that the places > > > where Actors were used were not necessary, added complexity to the code, > > and > > > had adverse performance characteristics. For example, as I added more > > > methods to LiftSession, I found that it became increasingly difficult to > > > choose between "methods" and "messages". The problem became acute when > > > Snippets and things external to LiftSession had to access LiftSession's > > > state during the servicing of a request. LiftSession needed public > > methods, > > > but those exposed state and thus the Actor model broke down. Yes, I > > could > > > have created a "CurrentLiftSessionState" object that was exposed only to > > the > > > current request via S (the thread-local state), but that seemed to be way > > > too complex. > > > > So, at this point, Actors are used for CometActors and to help service > > Comet > > > requests (event-based actors are used to suspend the long poll.) > > > > Does this help? > > > > Thanks, > > > > David > > > > > Thanks. > > > > - Debasish > > > > -- > > > Lift, the simply functional web frameworkhttp://liftweb.net > > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > > Follow me:http://twitter.com/dpp > > > Git some:http://github.com/dpp > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
