I see. So I looked up orElse and I see that it (and andThen) are methods of PartialFunction. Surprisingly, these aren't discussed at all in Programming in Scala. Apparently, they're beyond the scope of the book.
I understand the chaining and how this benefits the library designer (and the library consumer). I'm now reading through the source code and trying to get a better grasp of how partial functions benefit the Lift library. Thanks! Your answers really helped. BTW, if you do a search for Pf in the Lift code you'll find that there remain a couple of instances where the names haven't been changed to PF, namely line 259 of docs/presentations/lift-web-services/lift.html and lines 157 and 176 of src/main/scala/net/liftweb/http/CometActor.scala. Chas. Kris Nuttycombe wrote: > As David has mentioned before on this list (and as I believe is > mentioned in the book as well) the concerns of a library designer and a > library user are somewhat different. Allowing the user of a library to > provide a partial function makes development using that library easier > because the user doesn't need to worry about potential match errors, or > having to provide for each possible case in a match; they can just > define their partial function over the values that they're interested in > and rely upon the framework to do the right thing if no match is available. > > Internally, Lift will check isDefinedAt whenever a partial function is > used; this is an instance where the library designer takes on the > responsibility for providing correct handling in the undefined case, and > leaves the user free to handle whatever specific cases they wish. This > gives maximum flexibility to the users of the framework, and allows them > to focus on the problems they're trying to solve. > > Kris > > On Sat, Dec 27, 2008 at 1:18 AM, Marius <[email protected] > <mailto:[email protected]>> wrote: > > > Personally I think Partial functions are great because you can chain > them ... see orEse. The other nice thing is pattern matching on > function arguments. For instance: > > val x: PartialFunction[String,String] = { > case "dog" => "bark" > } > > this PF is defined only if the argument is "dog". For anything else > isDefined function returns false.But whenever you want to call a PF > you should first call the isDefinedAt. If in the example above we'd > use a complete function calling it with something else then a dog > you'll get a MatchError at runtime. > > So you'd call the above > > val arg = "dog" > if (x.isDefinedAt(arg)) { > x(arg) > } > > Br's, > Marius > > On Dec 27, 2:29 am, "Charles F. Munat" <[email protected] > <mailto:[email protected]>> wrote: > > As a holiday gift to myself I am reading Programming in Scala > from cover > > to cover. I've gotten as far as the pattern matching stuff and > there's a > > discussion of partial functions. PiS says: "In general, you > should try > > to work with complete functions whenever possible..." > > > > But I notice that the Lift code is filled with partial functions. > > They're all over the place. > > > > What is the benefit of using partial functions that outweighs the > > detriment of possible runtime errors? I'm trying to understand why > > partial functions might be useful. > > > > Thanks! > > Chas. > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
