Refactoring to Scala DSLs and LiftOff 2009 Recap
Download as ODP, PDF4 likes1,236 views
The document summarizes a presentation given on refactoring code to domain-specific languages (DSLs) in Scala. It provides an example of refactoring shell command execution code in Java into a DSL in Scala using techniques like implicit conversions and infix notation. The presentation argues that by applying Scala idioms carefully, code can be naturally refactored into a DSL tailored to the problem domain, providing a simple way to migrate code from Java to Scala.
![Scala LiftOff Recap and Refactoring to DSLs by David Orme Eclipse, Rich web, and Scala consulting [email_address] Presented to Chicago Area Scala Enthusiasts CASE](https://image.slidesharecdn.com/case-2009-091119162432-phpapp01/85/Refactoring-to-Scala-DSLs-and-LiftOff-2009-Recap-1-320.jpg)
![def f(elems: List[Int], x: Int = 0, cond: Boolean = true)](https://image.slidesharecdn.com/case-2009-091119162432-phpapp01/85/Refactoring-to-Scala-DSLs-and-LiftOff-2009-Recap-26-320.jpg)
Ad
More Related Content
What's hot (20)
Similar to Refactoring to Scala DSLs and LiftOff 2009 Recap (20)
Ad
Recently uploaded (13)
Ad
Refactoring to Scala DSLs and LiftOff 2009 Recap
- 1. Scala LiftOff Recap and Refactoring to DSLs by David Orme Eclipse, Rich web, and Scala consulting [email_address] Presented to Chicago Area Scala Enthusiasts CASE
- 2. Meeting Agenda Agenda: Scala LiftOff Recap
- 3. Refactoring to DSLs Techniques for migrating to Scala
- 4. Meeting Agenda Agenda: Scala LiftOff Recap
- 5. Refactoring to DSLs Techniques for migrating to Scala
- 6. Scala LiftOff Unconference format Began with Martin Odersky prepared keynote
- 7. (Some) Attendees came prepared to speak Created the schedule
- 9. Sessions were voluntarily merged
- 10. ...then we did it With so many really smart people present, it worked very well
- 11. Scala LiftOff Overall themes: Scala 2.8 improvements
- 12. Enterprise adoption: Status and opportunities
- 13. Killer applications / uses
- 15. Scala LiftOff Overall themes: Scala 2.8 improvements
- 16. Enterprise adoption: Status and opportunities
- 17. Killer applications / uses
- 19. Scala LiftOff Scala 2.8 – Selected Improvements New collections Consistency between mutable/immutable implementations with a single abstract parent defining the API for both
- 20. Paid off technical debt – eliminated implementation duplication throughout the library
- 21. Consistent implcit conversions to and from Java collections and Scala collections
- 22. Scala LiftOff Scala 2.8 – Selected Improvements Named parameters
- 23. def resize(width: Int, height: Int) = { ... }
- 24. resize(width = 120, height = 42) resize(height = 42, width = 120)
- 25. Scala LiftOff Scala 2.8 – Selected Improvements Default parameter values
- 26. def f(elems: List[Int], x: Int = 0, cond: Boolean = true)
- 27. f(List(1))
- 28. f(Nil, cond = false)
- 29. Scala LiftOff Scala 2.8 – Selected Improvements break is now implemented … as a library function!
- 31. breakable {
- 32. for (x <- elems) {
- 33. println(x*2)
- 34. if (x > 0) break
- 35. }
- 36. }
- 37. Scala LiftOff Scala 2.8 – Selected Improvements New and improved tool support New tooling supported directly in scala compiler
- 38. Brand new, much more stable Eclipse plugin.
- 39. Tight Java tooling integration
- 40. No more ”Project/Clean” or closing/reopening projects to reboot the compiler!
- 41. Same tool support also ported to NetBeans
- 42. Martin definitely ”gets it” about the importance of having high quality Scala tool support
- 43. Scala LiftOff Scala 2.8 – Selected Improvements Dave's verdict: Important changes at all levels of the Scala stack
- 44. 2.8 could be what causes Scala to cross the chasm into the mainstream
- 45. Scala LiftOff Overall themes: Scala 2.8 improvements
- 46. Enterprise adoption: Status and opportunities
- 47. Killer applications / uses
- 49. Scala LiftOff Enterprises that have adopted Scala Web 2.0 startups Twitter
- 50. Facebook
- 51. RTM
- 52. ... Financial industry, particularly in trading EDF Trading
- 53. Clarify
- 54. Swiss Quote
- 55. (some smaller financial firms)
- 56. Scala LiftOff How to introduce into an enterprise? Non-Prod uses More readable unit/integration tests
- 57. Build tooling, database loading, scripting, etc... Production uses A targeted module in a larger system
- 58. Often a DSL of some form
- 59. Scala LiftOff Remaining challenges Commercial support Formal training
- 60. Someone to sue
- 61. This situation is improving, especially in Europe Tooling (IDEs, CI infrastructure) 2.8 significantly improves this Licensing (perceived challenge) If it's free, it can't be any good
- 62. Yes, some people still say this, even in 2009!
- 63. Scala LiftOff Overall themes: Scala 2.8 improvements
- 64. Enterprise adoption: Status and opportunities
- 65. Killer applications / uses
- 67. Scala LiftOff Killer Applications/Uses DSLs in particular; more generally, anywhere greater abstraction is useful/needed
- 68. XML processing (since XML is a part of native Scala syntax)
- 70. Web templating engines Testing Specs, ScalaCheck Build, development lifecycle tooling SBT keeps coming up!
- 71. Scala LiftOff Overall themes: Scala 2.8 improvements
- 72. Enterprise adoption: Status and opportunities
- 73. Killer applications / uses
- 75. Scala LiftOff Thinking in Functions This thought came up again and again: Java (OO/Procedural) programs are a series of state mutations Change objects' state in-place; the ”result value” changes over time
- 76. A, A', A'', A''', … , A (n)
- 77. Scala LiftOff Thinking in Functions This thought came up again and again: Functional-style programs are a series of state transformations Transform one result to another repeatedly over time
- 78. A -> B -> C -> D -> … -> Z Notice how the identity/value of A always stays the same
- 79. Notice how this helps with threading and concurrency!
- 80. Scala LiftOff Thinking in Functions This thought came up again and again: Functional-style programs are a series of state transformations Transform one result to another repeatedly over time
- 81. A -> B -> C -> D -> … -> Z See also: Rich Hickey's presentation on InfoQ: Are we there yet? http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey?utm_source=twitterfeed&utm_medium=twitter
- 82. Scala LiftOff Thinking in Functions Ironically, LIFTWeb is a very stateful (OO-style) framework.
- 83. -> Make sure that your load-balancing server uses sticky sessions (that the same session always goes to the same server)
- 84. Scala LiftOff Any questions about the Scala LiftOff?
- 85. Overall themes: Scala 2.8 improvements
- 86. Enterprise adoption: Status and opportunities
- 87. Killer applications / uses
- 89. Meeting Agenda Agenda: Scala LiftOff Recap
- 90. Refactoring to DSLs Techniques for migrating to Scala
- 91. Refactoring to DSLs Refactoring to DSLs: Why? A good way to introduce Scala
- 92. Provides visible, incremental benefits
- 93. Refactoring to DSLs Refactoring to DSLs: How? Start with something painful or impossible in Java
- 94. Translate the basic idea into Scala
- 95. Apply Scala idiom(s) to improve code
- 96. ”Can we do better?”
- 98. Refactoring to DSLs Example: The O/S Shell DSL Simple file operations
- 99. Running O/S command and processing results I.e.: Perl ”back-tick operator” with variable contents interpolation @files = `ls $install_dir`
- 100. -> List files in $install_dir; place into @files array
- 101. Refactoring to DSLs @files = `ls $install_dir` Can we make Scala do (something like) this?
- 102. Refactoring to DSLs @files = `ls $install_dir` Interpolate variable contents into strings
- 103. Run a shell command and return results
- 104. Avoid cluttering code with new File(”something”) line noise when we already know we're working with files anyway
- 105. Refactoring to DSLs @files = `ls $install_dir` Interpolate variable contents into strings Translate the basic idea into Scala
- 106. Apply Scala idiom(s) to improve code
- 107. ”Can we do better?”
- 109. Refactoring to DSLs Start with: The Java Way, translated to Scala
- 110. val folder = "/home";
- 111. println("ls " + folder)
- 112. Can we do better? Not easily–if we start from this syntax
- 113. Plan B: Is there a way to interpolate ANYTHING into a String using regular Java or Scala?
- 114. Refactoring to DSLs What about this idea?
- 115. val folder = "/home";
- 116. val formatter = new java.util.Formatter()
- 117. println(formatter.format("ls %s", folder)) Pro: Now we're actually interpolating into the string
- 118. Con: More verbose! Can we do better?
- 119. Refactoring to DSLs What about this idea?
- 120. val folder = "/home";
- 121. val formatter = new java.util.Formatter()
- 122. println(formatter. format ("ls %s", folder)) What if we use Scala implicits to add the format method to java.lang.String?
- 123. Refactoring to DSLs Actually, Scala does that for us already. ;-P
- 124. val folder = "/home";
- 125. println("ls %s".format(folder)) Notice: In order to refactor TO a DSL, all we need to do is to switch the format method to use infix notation
- 126. Refactoring to DSLs Actually, Scala does that for us already. ;-P
- 127. val folder = "/home";
- 129. println("ls %s" format folder)
- 130. Refactoring to DSLs Actually, Scala does that for us already. ;-P
- 131. val folder = "/home";
- 133. println("ls %s" format folder) Pros: This isn't bad OO code
- 134. Cons: Asking a String (a data structure) to format another string, when it's really substituting that other string into itself doesn't seem right. Can we do better?
- 135. Refactoring to DSLs Add our own implicit conversion supplying synonyms for the #format method
- 136. val folder = "/home";
- 137. println("ls %s" substituting folder)
- 138. println("ls %s" << folder)
- 139. Notice: We have now created a simple DSL for variable interpolation into strings.
- 140. Refactoring to DSLs Let's go play with the code. :-)
- 141. Refactoring to DSLs @files = `ls $install_dir` Interpolate variable contents into strings
- 142. Run a shell command and return results Translate the basic idea into Scala
- 143. Apply Scala idiom(s) to improve code
- 144. ”Can we do better?”
- 146. Refactoring to DSLs Start with: The Java Way, translated to Scala
- 147. new PlatformExec("cat /etc/hosts").execPrint() Write a class that encapsulates Runtime.exec() nastiness
- 148. Instantiate it
- 149. Execute a method on it Can we do better?
- 150. Refactoring to DSLs What if we make that big OO thing into a single function call?
- 151. execute("cat /etc/passwd") Pros: Definitely simpler/easier to read
- 152. Cons: Still not nearly as convenient as back-tick notation Can we do better?
- 153. Refactoring to DSLs What if we add the execute method directly to java.lang.String using Scala's implicit type conversions? This enables us to write this:
- 154. for (line <- "ls".exec().split("\n")) {
- 155. println("-> " + line)
- 156. }
- 157. Refactoring to DSLs What if we add the execute method directly to java.lang.String as a lexically-scoped implicit? Or this:
- 159. println("=> " + file)
- 160. } Not bad. And sometimes this is perfect. But sometimes we just want a backtick operator! Can we do better?
- 161. Refactoring to DSLs We can add methods to java.lang.String, and operators are just methods.
- 162. Is there an operator that could reasonably mean ”execute” to a String?
- 163. Refactoring to DSLs How about unary_! as Scala's backtick operator? Then we can write: !"cat /etc/passwd" Or: val name = "Dave" !("echo I'm sorry, %s, I just can't do that" substituting name)
- 164. Pro: We now have a reasonable ”backtick” operator, and a lot of OO/FP flexibility as well.
- 165. Con: A lot of these operations would be better done with a straight java.io.File Can we do better?
- 166. Refactoring to DSLs @files = `ls $install_dir` Interpolate variable contents into strings
- 167. Run a shell command and return results
- 168. Avoid cluttering code with new File(”something”) line noise when we already know we're working with files anyway
- 169. Refactoring to DSLs Simply add an implicit conversion converting a java.lang.String into a java.io.File: implicit def string2File(s : String) = new java.io.File(s) Then we can write: for (file <- "/home/djo".list()) { println("==> %s" << file) }
- 170. Refactoring to DSLs Simply add an implicit conversion converting a java.lang.String into a java.io.File: implicit def string2File(s : String) = new java.io.File(s) Then we can write: for (file <- "/home/djo".list()) { println("=> %s" << file) } Or even:
- 172. Refactoring to DSLs Let's go play with the code. :-)
- 173. Refactoring to DSLs By carefully applying Scala idioms, we find ourselves naturally refactoring our code into a DSL that fits our problem domain -> Use Scala's infix notation to make OO code read like English
- 174. -> Wrap repetitive Java code in ”bridge classes”
- 175. -> When appropriate, make those ”bridge classes” available via implicit conversions
- 176. -> Carefully use operator overloading
- 177. Refactoring to DSLs By carefully applying Scala idioms, we find ourselves naturally refactoring our code into a DSL that fits our problem domain
- 178. This provides us with a simple, repeatable migration path off of Java, onto Scala
- 179. CASE Questions? Comments?
- 180. Presentation available on SlideShare