Mortimerp9

object test {
  
  /**
   * The companion object
   */
  object Reader {

/**
 *  automatically wrap a function in a reader 
 */

ramn

import annotation.tailrec
import scala.math.Ordering.Implicits._


object MergeSort {
  def apply[T : Numeric](xs: Seq[T]): Seq[T] = {
    val n = xs.length / 2
    if (n == 0)
      xs
    else {

aappddeevv

##Cake Pattern and Why Cake Patterns Sometimes Look Different The cake pattern is typically described as a way to use small layers of functionality to create a larger, more complex program. This area of application design is typically designed with application scalability not in the pure performance sense, but in the sense of scaling the application up to more complex functionality and maintainability over time.

There have been many papers and blogs on this aspect, but a few especially helpful blogs include:

• http://debasishg.blogspot.com/2010/02/scala-self-type-annotations-for.html
• http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di
• https://www.precog.com/blog-precog-2/entry/existential-types-ftw
• https://coderwall.com/p/t_rapw

aappddeevv

Scala and Cake Patterns and the Problem

Standard design patterns in scala recommend the cake pattern to help compose larger programs from smaller ones. Generally, for simple cake layers, this works okay. Boner's article suggests using it to compose repository and service layers and his focus is on DI-type composition. As you abstract more of your IO layers however, you realize that you the cake pattern as described does not abstract easily and usage becomes challenging. As the dependencies mount, you create mixin traits that express those dependence and perhaps they use self-types to ensure they are mixed in correctly.

Then at the end of the world, you have to mix in many different traits to get all the components. In addition, perhaps you have used existential types and now you must have a val/object somewhere (i.e. a well defined path) in order to import the types within the service so you can write your program. Existential

aappddeevv

#The Problem We just described standard design issues you have when you start creating layers of services, DAOs and other components to implement an application. That blog/gist is here.

The goal is to think through some designs in order to develop something useful for an application.

#Working through Layers If you compose services and DAOs the normal way, you typically get imperative style objects. For example, imagine the following:

  object DomainObjects {

dragisak

import scalaz._
import Scalaz._
import Lens._

/*

Examples of Scalaz lenses

*/

lossyrob

  def write(path: String, txt: String): Unit = {
    import java.nio.file.{Paths, Files}
    import java.nio.charset.StandardCharsets

    Files.write(Paths.get(path), txt.getBytes(StandardCharsets.UTF_8))
  }
  
  def read(path: String): String =
    scala.io.Source.fromFile(path, "UTF-8").getLines.mkString

odersky

/** This is in reference to @tploecat's blog http://tpolecat.github.io/2015/04/29/f-bounds.html
 *  where he compares F-bounded polymorphism and type classes for implementing "MyType".
 * 
 *  Curiously, the in my mind obvious solution is missing: Use abstract types.
 * 
 *  A lot of this material, including an argument against F-bounded for the use-case
 *  is discussed in:
 * 
 *  Kim B. Bruce, Martin Odersky, Philip Wadler:
 *  A Statically Safe Alternative to Virtual Types. ECOOP 1998: 523-549