The Hidden Nature of Data – BOBKonf 2017

Encapsulation is a pillar of object-oriented programming, but how important is it in the context of functional programming? Is it worth clinging to, or should we stay away? This talk will examine the tradeoffs of encapsulating internal representations versus exposing the "nature" of our data.

Programming with immutable values and algebraic data types usually makes hiding fields behind accessors unnecessary. On the other hand, hiding functions and types is a crucial technique control our API, encouraging correct usage and affording the flexibility to change it.

In this session we will explore constraints that encourage encapsulation, discuss how it affects our types, their algebras, and their algorithmic properties, and learn about alternatives and their benefits and drawbacks.

Transcript

1. The Hidden Nature of Data BOBKonf 2017 Martin Kühl, @mkhl
2. Motivation
3. Paul Chiusano and Rúnar Bjarnason
4. One might object that algebraic data types violate encapsulation by making public the internal representation of a type. […] Exposing the data constructors of a type is often fine, and the decision to do so is approached much like any other decision about what the public API of a data type should be.
6. But
7. Stackless Scala With Free Monads, Rúnar Bjarnason sealed trait Free[S[+_],+A] { private case class FlatMap[S[+_],A,+B]( a: Free[S,A], f: A => Free[S,B]) extends Free[S,B] }
8. So when is exposing our data constructors not fine? And what does that mean for when we should use pattern matching?
9. Example
10. Example: List case object Nil extends List[Nothing] case class Cons[+A](head: A, tail: List[A]) extends List[A] sealed trait List[+A] { def fold[B](z: B)(f: (A, B) => B): B = this match { case Nil => z case Cons(h, t) => f(h, t.fold(z)(f)) } def append[B >: A](that: List[B]): List[B] = this.fold(that)(Cons(_, _))
11. Example: List + Append case object Nil extends List[Nothing] case class Cons[+A](head: A, tail: List[A]) extends List[A] private case class Append[+A](left: List[A], right: List[A]) extends List sealed trait List[+A] { def fold[B](z: B)(f: (A, B) => B): B = this match { case Nil => z case Cons(h, t) => f(h, t.fold(z)(f)) case Append(l, r) => l.fold(r.fold(z)(f))(f) } def append[B >: A](that: List[B]): List[B] = (this, that) match { case (_, Nil) => this case (Nil, _) => that case _ => Append(this, that) }
12. Problems
13. It breaks pattern matching [warn] /path/to/Service.scala:28: match may not be exhaustive. [warn] It would fail on the following input: Append(_, _) [warn] def go(as: List[A], count: Int): Int = as match { [warn] ^
14. It violates “No Confusion”
15. No Junk, No Confusion — Joseph A. Goguen
16. It changes our algebra
17. Advice
18. Be conservative in what you do, be liberal in what you accept from others. — Jon Postel
19. Is your library providing a language or interpreting one?
20. If you are providing a language, try to expose its structure
21. If you are interpreting a language, try consuming interfaces
22. If you are introducing interfaces, don’t replace existing structures
23. Changes to existing structures should affect downstream code
24. Pattern matching can be nested
25. Pattern matching can be nested case (Some(Foo(x)), Right(Bar(y))) => …
26. More flexibility in defining types case class Prog[A](get: Free[Lang, A]) vs. type Prog[A] = Free[Lang, A]
27. Pattern matching Try to use and support it
28. Martin Kühl Thank you! Questions? Comments? @mkhl martin.kuehl@innoq.com