Qual è il valore aggiunto del modello di progettazione della programmazione funzionale di Kestrel? (Scala)

Question

Mi chiedo perché è così utile mettere via la parte dell'effetto collaterale di un codice usando Kestrel. Qualcuno ha esperienza con esso? e può spiegare la vera motivazione e come aiuta esattamente.

Anche se capisco che la programmazione funzionale pura riguarda l'effetto zero-side e, d'ora in poi, il debugging e la prevedibilità del codice. Tuttavia, nel caso di Kestrel, non vedo come sia davvero utile farlo?

migliore,

MM-

Answer 1

Il punto è quello di evitare di creare una variabile intermedia che probabilmente non si vuole essere in giro, o per evitare di dover creare un nuovo blocco per qualcosa che' fare di passaggio. Supponiamo di avere il gheppio come in Ruby:

implicit class RubyKestrel[A](val repr: A) extends AnyVal { 
    def tap[B](f: A => B) = { f(repr); repr } 
} 

Ora supponiamo abbiamo qualche riga di codice:

xs.map(_ + 7).filter(foo).take(n) 

e vogliamo stampare un messaggio di debug dopo il filtro. Senza tap abbiamo refactoring quella linea a:

{ 
    val temp = xs.map(_ + 7).filter(foo) 
    println(temp) 
    temp.take(n) 
} 

Ugh. Ora supponiamo di avere tap:

xs.map(_ + 7).filter(foo).tap(println).take(n) 

Accidenti, modo migliore!

Supponiamo di disporre di uno stack con un metodo di aggiunta e di aggiungere qualcosa allo stack prima di utilizzarlo da qualche altra parte.

def newStack = { 
    val stack = new Stack 
    stack add "whatever" 
    stack 
} 

Ugh. Ma con tap:

def newStack = (new Stack).tap(_ add "whatever") 

piuttosto comodo - è in realtà solo consente di trasformare qualsiasi metodo side-effettuando normale in qualcosa che si può chiamate a catena. E dal momento che le chiamate incatenate sono spesso più basse, è spesso una grande vittoria.