Sätze für lau

Transcript

1. Sätze für lau Die fünf Phasen der Trauer über Type Reification Lars Hupel 29. April 2017
2. Über mich ▶ Doktorand an der Technischen Universität München ▶ forscht im Bereich der Softwareverifikation ▶ 10-jähriges Konferenzjubiläum 2
3. Fazit 1. Type Erasure ist nicht schlecht, sondern gut. 2. Es gibt zu wenig Type Erasure. 3. Neue Typparameter braucht das Land. 4. In Scala ist alles besser. 3
4. Verweigerung
5. Java und Generics Java 5 (September 2004) brachte uns Generics. ▶ List<String> statt List ▶ list.get(0) statt (String) list.get(0) ▶ Syntax inspiriert von C++ ▶ aber: komplett anders implementiert! 5
6. Type Erasure ≈ 629k ≈ 1310k 6
7. Warum ist Type Erasure so unbeliebt? Fast jede Java-Programmiererin ist schon einmal darüber gestolpert ... 7
13. ... 36 Seiten
14. Begriffsklärung Typsystem “ A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute. ” Benjamin Pierce 14
15. Begriffsklärung Typsystem “ A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute. ” Benjamin Pierce 14
16. Begriffsklärung Typsystem “ A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute. ” Benjamin Pierce 14
17. Begriffsklärung Typsystem “ A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute. ” Benjamin Pierce 14
18. Begriffsklärung Typsystem “ A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute. ” Benjamin Pierce 14
19. Laufzeittypen 1. Folgerung Der Compiler verwirft Information 15
20. Laufzeittypen 1. Folgerung Der Compiler verwirft Information 2. Folgerung „Laufzeittyp“ ist ein Widerspruch in sich 15
21. Laufzeittypen 1. Folgerung Der Compiler verwirft Information 2. Folgerung „Laufzeittyp“ ist ein Widerspruch in sich 3. Folgerung Typdispatching ist zum Scheitern verurteilt 15
22. Laufzeittypen 16
23. Laufzeittypen 16
24. Zorn
25. Ko- und Kontravarianz Annahme: unveränderliche Collections Java List<Dog> goodDogs = new List<Dog>(); List<? extends Animal> goodAnimals = goodDogs; 18
26. Ko- und Kontravarianz Annahme: unveränderliche Collections Java List<Dog> goodDogs = new List<Dog>(); List<? extends Animal> goodAnimals = goodDogs; Scala val goodDogs: List[Dog] = List.empty val goodAnimals: List[Animal] = goodDogs 18
27. Ko- und Kontravarianz Annahme: unveränderliche Collections Java (“use site”) List<Dog> goodDogs = new List<Dog>(); List<? extends Animal> goodAnimals = goodDogs; Scala (“declaration site”) val goodDogs: List[Dog] = List.empty val goodAnimals: List[Animal] = goodDogs 18
28. Ko- und Kontravarianz Reifizierte Generics führen zu zwei Problemen: 1. Festlegung auf “use site”-Varianz 2. Laufzeitprüfung von parametrisierten Subtyp-Beziehungen 19
32. Verhandlung
33. Warum nicht alles reifizieren? 23
34. Situation in C# C# hat reifizierte Generics ... 24
35. Situation in C# C# hat reifizierte Generics ... ... erkauft durch duplizierte APIs 24
36. Situation in Haskell -- Sigh. This is horrible, but then so is unsafeCoerce. unsafeCoerce :: a -> b 25
37. Situation in Haskell -- Sigh. This is horrible, but then so is unsafeCoerce. unsafeCoerce :: a -> b -- The type-safe cast operation cast :: (Typeable a, Typeable b) => a -> Maybe b 25
39. Begriffsklärung Polymorphismus Subtyp-Polymorphismus Die konkrete Methode, die bei einem Aufruf obj.f(x) aufgerufen wird, ist erst zur Laufzeit ermittelbar. 27
40. Begriffsklärung Polymorphismus Subtyp-Polymorphismus Die konkrete Methode, die bei einem Aufruf obj.f(x) aufgerufen wird, ist erst zur Laufzeit ermittelbar. Parametrischer Polymorphismus Eine Funktion (oder Klasse) ist nicht nur über Werte, sondern auch über Typen parametrisiert. 27
41. Begriffsklärung Polymorphismus Subtyp-Polymorphismus Die konkrete Methode, die bei einem Aufruf obj.f(x) aufgerufen wird, ist erst zur Laufzeit ermittelbar. Parametrischer Polymorphismus Eine Funktion (oder Klasse) ist nicht nur über Werte, sondern auch über Typen parametrisiert. Ad-hoc-Polymorphismus Die Implementierung einer überladenen Methode (häufig: Operator) wird vom Compiler statisch an Hand der involvierten Typen selektiert. 27
42. Begriffsklärung Polymorphismus Subtyp-Polymorphismus Die konkrete Methode, die bei einem Aufruf obj.f(x) aufgerufen wird, ist erst zur Laufzeit ermittelbar. Parametrischer Polymorphismus Eine Funktion (oder Klasse) ist nicht nur über Werte, sondern auch über Typen parametrisiert. Ad-hoc-Polymorphismus Die Implementierung einer überladenen Methode (häufig: Operator) wird vom Compiler statisch an Hand der involvierten Typen selektiert. 27
43. Subtyp-Polymorphismus Quellcode obj.toString(); 28
44. Subtyp-Polymorphismus Quellcode obj.toString(); Bytecode invokevirtual #24 // Method java/lang/Object.toString:()Ljava/lang/String; 28
45. Parametrischer Polymorphismus Quellcode def map[A, B](list: List[A], f: A => B): List[B] 29
46. Parametrischer Polymorphismus Quellcode def map[A, B](list: List[A], f: A => B): List[B] Signatur public <A, B> List<B> map(List<A>, Function1<A, B>); 29
47. Parametrischer Polymorphismus Quellcode def map[A, B](list: List[A], f: A => B): List[B] Signatur public <A, B> List<B> map(List<A>, Function1<A, B>); Laufzeit > meth.toString() public List Bla.map(List,Function1) 29
48. Ad-hoc-Polymorphismus Stark vereinfacht: syntaktisches Überladen trait Number { def +(x: Int): Number def +(x: Float): Number def +(x: Number): Number } 30
49. Begriffsklärung YAGNI 31
50. YAGNI und Typen 32
51. Mehr Typparameter! Traditioneller Entwurf case class BlogPost( date: Date, title: String, author: User, text: String ) 33
52. Mehr Typparameter! Parametrischer Entwurf case class BlogPost[T]( date: Date, title: String, author: User, text: T ) 33
53. Mehr Typparameter! Parametrischer Entwurf case class BlogPost[T]( date: Date, title: String, author: User, text: T ) Vorteile ▶ BlogPost interessiert sich nicht für den Text: ▶ kodiert (UTF-8) ▶ dekodiert (Codepoints) ▶ internationalisiert (Map[Language, Text]) ▶ escaped (HTML) 33
54. Mehr Typparameter! Parametrischer Entwurf case class BlogPost[T]( date: Date, title: String, author: User, text: T ) Vorteile ▶ Operationen interessieren sich nicht für den Text: ▶ Archivübersicht ▶ Publikation ▶ Bearbeiten von Metadaten 33
55. Mehr Typparameter! Parametrischer Entwurf case class BlogPost[T]( date: Date, title: String, author: User, text: T ) Vorteile ▶ Sätze für lau 33
56. Sätze für lau ▶ basierend auf „Parametrizität“ ▶ vereinfacht: Funktion mit Typparameter weiß nichts und darf nichts 34
57. Sätze für lau ▶ basierend auf „Parametrizität“ ▶ vereinfacht: Funktion mit Typparameter weiß nichts und darf nichts Beispiel // Signatur beschreibt exakt eine mögliche Funktion public <T> T id(T t); 34
58. Sätze für lau ▶ basierend auf „Parametrizität“ ▶ vereinfacht: Funktion mit Typparameter weiß nichts und darf nichts Fortgeschrittenes Beispiel // Summary enthält nicht den Text public <T> Html renderSummary(BlogPost<T> post); 34
59. Sätze für lau ▶ basierend auf „Parametrizität“ ▶ vereinfacht: Funktion mit Typparameter weiß nichts und darf nichts Fortgeschrittenes Beispiel // Summary enthält nicht den Text public Html renderSummary(BlogPost<?> post); 34
60. Sätze für lau ▶ basierend auf „Parametrizität“ ▶ vereinfacht: Funktion mit Typparameter weiß nichts und darf nichts Beispiel aus der Bibliothek list.map(f).map(g) == list.map(f andThen g) list.map(f).filter(g) == list.filter(f andThen g).map(f) 34
62. (Gebundene) Namen sind Schall und Rauch “ What’s in a name? that which we call a rose By any other name would smell as sweet ” Shakespeare 36
63. (Gebundene) Namen sind Schall und Rauch “ What’s in a name? that which we call a type parameter By any other name would still be parametric ” Reynolds 36
64. Verbotene Dinge ▶ null ▶ Exceptions (außer Error, sofern unfangbar) ▶ isinstanceof ▶ Casting ▶ equals, toString, hashCode ▶ getClass ▶ globale Seiteneffekte 37
65. Verbotene Dinge ▶ null ▶ Exceptions (außer Error, sofern unfangbar) ▶ isinstanceof ▶ Casting ▶ equals, toString, hashCode ▶ getClass ▶ globale Seiteneffekte 37
66. Depression
67. Aber ich brauche Sammlungen von Objects ... 39
68. Metaprogrammierung “ Metaprogramming is a workaround for an abstraction your programming language doesn’t have yet. ” 40
69. Metaprogrammierung “ Metaprogramming is a workaround for an abstraction your programming language doesn’t have yet. ” In Java ist Metaprogrammiering (Reflection) grundsätzlich unsicher. 40
70. Was kann man tun? Lösungsvorschlag ▶ “Super Type Tokens” nach Neal Gafter,1 2006 ▶ ermöglicht “Typesafe Heterogeneous Containers” 1https://gafter.blogspot.de/2006/12/super-type-tokens.html 41
71. Was kann man tun? Lösungsvorschlag ▶ “Super Type Tokens” nach Neal Gafter,1 2006 ▶ ermöglicht “Typesafe Heterogeneous Containers” public abstract class TypeToken<T> {} new TypeToken<List<Int>> {} 1https://gafter.blogspot.de/2006/12/super-type-tokens.html 41
72. Type Tokens in Scala scala> classTag[List[Int]] res0: ClassTag[List[Int]] = List scala> typeTag[List[Int]] res1: TypeTag[List[Int]] = TypeTag[List[Int]] 42
73. Type Tokens in Scala scala> classTag[List[Int]] res0: ClassTag[List[Int]] = List scala> typeTag[List[Int]] res1: TypeTag[List[Int]] = TypeTag[List[Int]] scala> def foo[T] = typeTag[T] <console>:17: error: No TypeTag available for T def foo[T] = typeTag[T] scala> def foo[T] = weakTypeTag[T] foo: [T]=> WeakTypeTag[T] 42
74. Akzeptanz
75. In der Praxis? Feststellung Type Erasure ist gut. 44
76. In der Praxis? Feststellung Type Erasure ist gut. Problem ▶ sichere Abhilfen existieren (z.B. Scala) ▶ aber: bringen wenige Vorteile gegenüber Type Reification 44
77. In der Praxis? Feststellung Type Erasure ist gut. Problem ▶ sichere Abhilfen existieren (z.B. Scala) ▶ aber: bringen wenige Vorteile gegenüber Type Reification ▶ besser: Entwurfsmuster überdenken 44
78. Typgetriebene Entwicklung Leitlinien ▶ konkrete Typen vermeiden ▶ Implementation durch Typen einschränken ▶ Compiler als Hilfe, nicht als Hindernis ▶ ungültige Zustände unrepräsentierbar machen ▶ “Type Tetris”2 2http://underscore.io/blog/posts/2017/04/11/type-tetris.html 45
80. new T ▶ gängiges Problem: Erzeugung einer Instanz ▶ Welche Instanz? ▶ Wie verhält sich die Instanz? ▶ Welche Parameter? 47
81. Monoide // Laws: // combine(x, empty) == x // combine(combine(a, b), c) == combine(a, combine(b, c)) trait Monoid[T] { def empty: T def combine(t1: T, t2: T): T } 48
82. Monoide // Laws: // combine(x, empty) == x // combine(combine(a, b), c) == combine(a, combine(b, c)) trait Monoid[T] { def empty: T def combine(t1: T, t2: T): T } def mapReduce[A, B : Monoid](list: List[A], f: A => B): B 48
83. Monoide // Laws: // combine(x, empty) == x // combine(combine(a, b), c) == combine(a, combine(b, c)) trait Monoid[T] { def empty: T def combine(t1: T, t2: T): T } def mapReduce[F[_] : Foldable, A, B : Monoid] (as: F[A], f: A => B): B 48
84. Optics 49
85. Schlusswort “ Wie kann ich wissen, was ich denke, wenn der Compiler es noch nicht überprüft hat? ” Der Franzose 50
86. Schlusswort “ Dokumentation ist unwichtig. Typsignaturen sind wichtig. ” Michael Wiedeking 50
87. Schlusswort “ Einen Test, der durch das Typsystem überflüssig geworden ist, sollte man löschen. ” David Tanzer 50
88. Q & A  larsrh  larsr_h