Player is loading...
Polymorphism in Scala
Petra Bierleutgeb
Wednesday, June 12, 2019 · 12:17 p.m. · 41m 23s
Polymorphism in computer science is an important concept for abstraction. In this talk we'll start by introducing three main types of polymorphism and their implementation in Scala. We'll delve into subtyping, parametric polymorphism and ad-hoc polymorphism and cover related concepts, such as type variance and context bounds. We'll compare subtyping and ad-hoc polymorphism (and type classes in particular) and discuss why the latter has become increasingly popular - especially in the community of FP-oriented programmers. The talk concludes with a preview of some of the new and exciting features planned for Dotty. Requir
Embed
Transcriptions
Note: this content has been automatically generated.
00:00:00
um hello everybody um to welcome to my talk about polymorphism summoned skull
00:00:05
yeah it's really good to be here at the ten year anniversary of salad days
00:00:10
and it was also about ten years ago that i first looked into scholar
00:00:15
and it's great to ten years later here and talk to use a speaker
00:00:21
and what attracted me first discuss uh i guess was to mix of um functional
00:00:27
programming and object oriented programming so i'm ten years ago i came from a java background
00:00:35
and what most people associate with the pole
00:00:39
nor for some it's also object oriented programming
00:00:43
but in fact um polymorphism itself is not
00:00:47
really i'm bound to one type of programming
00:00:52
and in this talk i'm i'm going to show you um the main different types of
00:00:59
uh put amorphous some and how they are um written style okay so to begin with um
00:01:09
short definition of the word polymorphism which i'm
00:01:12
simply means um many forms and this name
00:01:17
refers to the fact that it's sinking interface
00:01:20
or method um can be used with different types
00:01:25
and depending on the type of pull more for some um that met thought or interface
00:01:33
acts either independently of the provider type so it does the same thing for all the types
00:01:40
well still on maintaining type safety or it could um two different things or
00:01:48
um executed different implementation depending on the based um based on the provide type uh
00:01:56
so in general there um three different kinds of pull
00:02:01
more for some um the first were defined in the sixties
00:02:06
um by christopher straight he and he
00:02:11
um define two types the uh basically to uh
00:02:15
talk pull more for some and parametric polymorphism some
00:02:19
so in the first we have a polymorphic function um that can take
00:02:25
different um types and depending on the type it will execute a different
00:02:32
oh logic or implementation and in the second case we have to parametric
00:02:37
ample amorphous um that's a generic function that works with many different types
00:02:43
but the difference to a couple more for some is that implementation is actually
00:02:47
independent of the provided type and will execute the same logic for all the types
00:02:54
later in the eighties um fun object oriented programming caught more um popular
00:03:00
there was a third type of polymorphism step list or
00:03:05
named um and this is some inclusion polymorphism op or what's better known as stop typing it
00:03:13
and in this case um it it's basically says that you're about to use up
00:03:18
type as of any type t. i. number error type to use required or so
00:03:27
um this was a short intro and we're going to look at the different kinds
00:03:31
of polymorphism in more detail now i'm at the beginning i also have a recommendation for
00:03:36
reading material um there's this excellent book called extensions colour
00:03:40
which is kindly provided by the people from underscore for free
00:03:44
um if you like it you can donate to the title of the
00:03:47
project and it's definitely good reading if you're interested uh in the topic
00:03:53
uh so let's and start with the first type of polymorphism some witches
00:03:59
parametric polymorphism some some of you might also nor does generics i'm from java
00:04:07
and in this case we can have um either
00:04:10
a generic function or method or a generic data type
00:04:15
and the implementation in this case does not depend on the type
00:04:19
that we provide so if you look at example at the bottom
00:04:24
um we have a box in this case it's a generic data type
00:04:28
and we don't really care what kind of type we put into the box
00:04:34
but what we do care about is that when we look at the elemental to put inside or peak
00:04:40
um we want to to see the same type that we put into it
00:04:47
so as a comparison um if you've been programming long enough
00:04:52
you might still remember um versions of java but didn't have generics
00:04:56
so um if we look at the two examples here the one at the top um is one
00:05:03
that you're used to so you can use type parameters on the data type in this case the box
00:05:09
and when you put a type a an element of
00:05:12
this type inside you guaranteed and the compiler can check
00:05:17
but you're into you'd get the same type of element out of it
00:05:22
if we wouldn't have this kind of pull more for some um
00:05:26
and we just had a boxed and whatever we put inside um
00:05:31
even if it's an inch before we would lose to kind of type information and
00:05:35
the compiler wouldn't be able to tell us anymore what we take out of the box
00:05:45
this is especially useful when we work on data types like
00:05:48
uh containers so in this case we have a list of talks
00:05:53
and when we run the methods on this container in this case for each um
00:05:59
as you can see here at the bottom um to compile is able to help us
00:06:04
and knows that each type in this uh contain a
00:06:08
is a talk and so we're able ins for each method
00:06:12
call my thoughts um of fields or reference fields are defined on this data type
00:06:22
also or one more example if you look here um
00:06:26
again we have a container of a specific type and it's
00:06:31
when we call a polymorphic a method in this case that operates on the type to you um
00:06:39
in this line lines number six here one because the method second with the list of talks
00:06:45
this type parameter will be bound to talk and for this reason um we're able
00:06:51
or we know that the results of this method call will be an option of talk
00:06:57
i'm here to bottom um you see basically how you can imagine that's so
00:07:02
type parameter dozens free in this example above there will be pontoon type talk when you call the method
00:07:12
so to sum up um parametric polymorphism
00:07:17
um it can be used to basically abstract over types um so
00:07:21
provide implementations other independent of the type which makes some programs more expressive
00:07:27
and it's it's still maintains type safety
00:07:31
and steam basically the the most defining facts
00:07:36
um compared to other types of polymorphism is that implementation is independent of the type parameter
00:07:44
so on the other hand when we look at a talk pull more fearsome which is also sometimes known as overloading
00:07:51
um again we have a methods that we can uh um call
00:07:55
with different uh types but in this case um t. implementation actually
00:08:01
depends on the type that we provide so in this
00:08:04
case we can have several methods named a combined and
00:08:09
depending on the type of the parameter that we provide
00:08:12
uh the compatible choose a specific implementation and execute that code
00:08:22
i'm appalled more fake or talk polymorphic function um
00:08:28
it's basically identified by combination off it's i'm the type of the
00:08:33
parameters um toward of the parameters and also the result types so
00:08:41
in this case um as you can see we have several methods with the same name
00:08:48
but they have different uh types of parameters and because they are all different types um
00:08:53
we're still able to name them the same because the compiler can differentiate based on the types
00:09:04
one problem um that can come up um in this case is um they
00:09:09
uh cost but type or asia as you may know and the j. v. m.
00:09:13
um the run time type of um
00:09:16
parameters types um is basically erased so
00:09:21
in this case is a little bit tricky um so or a mighty surprising
00:09:25
so wise the first example working and the one at the bottom is not
00:09:32
um the reason is that um at run time
00:09:37
the type of the first um method or function will be you from this to int
00:09:43
and the second one will be foremost the strings that also still um it's still possible to
00:09:50
um differentiate between them but in the second case we have to
00:09:53
combine my thoughts um that are both going from list a string
00:09:57
and in this case the compilers complaining that there are two methods with the same name and same types
00:10:06
i'm also um the topple amorphous some misusing phone or
00:10:12
the um decision which method to call 'em is made will use what is
00:10:17
called early binding it's made at compile time so when we look at this example
00:10:23
um we have a little um start typing hierarchy euro from any
00:10:29
male animal with a two sub types the dog and the cat
00:10:33
and we have a greeting method that accepts one type of two three
00:10:40
and depending on the type that is provided we will output a different greeting
00:10:47
so here's a little quits um if you see that code or a free but if
00:10:51
we write that code so we define three variables and then call the method with that um
00:10:59
what would you expect would be the output of this program so who is for me
00:11:07
which would be
00:11:10
okay it's more like um yeah so in a talk
00:11:15
polymorphism some um the compiler looks at the at the
00:11:19
type defined here so even if we assign the talk to this variable it will treat it as an animal
00:11:26
and for this reason select this implementation so the first one here
00:11:36
so talk polymorphism it's basically method overloading
00:11:40
and the implementation is selected based on the type i'm undecided at compile time
00:11:47
um on the j. v. m. we have to watch out for um type or a sure
00:11:52
and it's got a a pattern that's often found um that i talk polymorphism patton
00:11:58
is so the typecast button and we will take a close look at just had done
00:12:04
um after talking talking about um start typing polymorphism first
00:12:13
so the third um kind of pull more for some that we're going to look at is stop typing
00:12:19
also sometimes called inclusion powerful poem or for some
00:12:24
and it's most often that kind of polymorphism the people
00:12:28
coming from an object oriented background uh most familiar with
00:12:32
so it basically says that we can use a subtype t. wherever we um expect the super tight ads
00:12:38
and in sky that's such relationships are expressed by extending traits or classes
00:12:46
so let's look at the short example here um again we have
00:12:50
an animal and to concrete a sub classes and in this case um
00:12:58
the sub types need to need to provide implementations for
00:13:03
all the methods or fields that are defined i'm super type
00:13:07
so since we don't provide an implementation on animal for name um utterance is
00:13:12
required the dog and cats implement um that field are provided field um we could
00:13:19
um leave out the greeting um but we can still or also we we could still
00:13:24
define the more specific um implementation for it in this case
00:13:29
we can overrides the definition that provided by the super type
00:13:36
i'm i'm like a topple amorphous um um
00:13:40
start typing has so late binding so if we
00:13:44
look at the uh same example from before um as you might have guessed i'm in this case
00:13:51
the compiler is not i'm looking at um at animal
00:13:56
type definition here but it's looking um at the concrete type that is provided
00:14:01
so in this example um the output will be different from before
00:14:06
and we will see that also the second method call will output the greeting for talk
00:14:16
in summary we can say that's gal
00:14:19
has therefore will the binding for method parameters
00:14:23
and plates binding for the object on which to methodist cold
00:14:33
so
00:14:36
um regarding all the different types of pull more for some their own
00:14:40
couldn't that parts and start typing is different and
00:14:43
it definitely very natural way of mafia wanting theatre
00:14:47
so it's really good for 'em modelling module product data types
00:14:52
which is probably a pattern that you know that uses your traits and a finer case classes or
00:14:58
and also if we have a subtype higher he um
00:15:02
it's very easy to add new data without modifying existing code
00:15:07
um which also pizzas to the uh not acquired part of sub
00:15:10
type thing which is that uh whenever we want to add new functionality
00:15:15
and we added to a certain traits we have to modify source codes in several different places
00:15:23
and also we are not able to implement traits on classes that
00:15:28
we don't uh own so that we don't have to source code for
00:15:32
and we can only um provide one implementation per type
00:15:39
and in bigger um projects um start typing tends to
00:15:44
will be two very complicated and inflexible as inflexible hierarchies
00:15:50
and there's also the in famous or return current type problem where i encourage you that so there is
00:15:56
a link in the slide it's basically that um if you implement the method on the super super type and
00:16:04
you're not able even if you call it on a concrete subtype to real return the current type
00:16:09
and there is a really great blog post written by robert norris so if you're interested
00:16:14
in this topic but i really don't suggest that you go and read this blog post
00:16:22
so before we dive into a tight classes let's have a look at
00:16:26
variance and type pounds which could basically seen as fine tuning for type parameters
00:16:36
so variance um defines the sup typing relationship
00:16:40
but between types to take a type parameter
00:16:43
um one example would be again contain as um
00:16:49
if we go back to the example from before to our little box that we defines um
00:16:54
variance answers to questions so if we have a box takes a type around it a t. or a
00:17:01
and we have a sub typing relationship between certain types like
00:17:05
our animal and the dog or cat then what is the relation
00:17:10
of a box of animals to a box of box and the
00:17:15
possibilities um are that there could be no relationship between them so
00:17:22
in this example um if we have a box of talks we
00:17:27
can't use it in a place very expects a box of animals
00:17:32
even if there's a sub piping relationship between animal and talk uses the default install also if
00:17:37
we just a right to type parameter here and put nothing else there then it will be invariant
00:17:45
another possibility that some of the founding contain
00:17:49
as um is that it's actually call variant um
00:17:54
because in this example um it would be safe safe
00:17:58
to say that if we have a box of animal
00:18:01
and in this case it's a read only so we're not able to update the element that's inside the box
00:18:08
um in this case it's safe to say that we can use a box of animal uh a box of talk
00:18:14
rather we expect the box of animal because all we can do is look at the element inside or
00:18:20
take it out and then we get out the subtype and we can use it forever we expect super type
00:18:27
the complete opposite is a contra variance
00:18:32
and i guess this one is the trickiest to understand um what it's a
00:18:36
useful for but it's basically the other way around so if we have a
00:18:42
um a place or parameter very um we are writing data are mutating data um
00:18:50
a box of use basically missed input type of box of a if basis up type of
00:18:57
he uses up type of a so um
00:19:01
it does make sense if you um thing about that
00:19:06
you're able to put a dog inside a box of animal without um
00:19:12
yeah while waiting any type constraints so that you're able to use a
00:19:16
box of animal wherever you expect a box of stock and basically with
00:19:22
this explanation that you're able to use the box of animal where you
00:19:25
expect a box of talk is the definition of us up typing hierarchy so
00:19:31
in this case it's better a around from before so if we you'd say it's something or
00:19:37
take a parameter uh it's uh usually control variant something that something
00:19:44
that you also might see ends colour codes um is a type ons
00:19:49
and in this case it's just um important even if you probably want to use it very
00:19:55
often your own code um that you're i'm able to read it and understand what it's saying
00:20:01
so in this case it simply saying uh if you have a type
00:20:04
around it and you see something like a um then the small are um
00:20:10
find of the uh it says that a must be a subtype of p. and there's also
00:20:15
the other way around that we can say a must be super type of you know so
00:20:22
now with that knowledge uh we can start to look at something or
00:20:27
but interesting um that has become um more and
00:20:31
more popular lately which are type classes and stardom
00:20:36
so type classes first appeared and has care and there is a uh like a
00:20:43
paper that describes it um that's called hard to make
00:20:46
it talked baltimore for some nice to talk and basically it
00:20:50
allows implementing an interface for types that are not related by any
00:20:55
type hierarchy and another benefit is the the existing code that we have um and like
00:21:02
in subtype input amorphous some we don't have to uh modify an existing classes to implement
00:21:09
you interfaces for it and it's got uh we don't have a special syntax for
00:21:15
defining type closets but it's a pattern
00:21:18
that uses um several language features and implicit
00:21:28
so before we define a on type class let's look
00:21:31
at a use case um were how to use it so
00:21:35
many of you have problems we um worked with ordering or had to sorta list of something
00:21:43
in the past and it's got a provides a type class called ordering in the standard lip
00:21:50
and we can implement instances of this type clothes for on types which is
00:21:58
great and we can also implement um
00:22:03
order rings for types that we don't control or what where we don't on the source code
00:22:08
so this is like a week um advantage about providing it traits
00:22:12
because otherwise they could be a trait ordering which we could also extend
00:22:16
but if there was only a trait that we had to extend
00:22:19
frequent implement ordering for classes that come from external char files for example
00:22:27
and another advantage over a sub typing is that
00:22:31
and accept typing we can have multiple different implementations prototype
00:22:35
so it would be pretty bad if we could only find one ordering for integers and it's
00:22:43
maybe one time we want to um order it s. ending and the other side a descending
00:22:49
or order it on some kind of a property and for this reason
00:22:53
it's really important that you can find an ordering for several type uh
00:22:57
several or hearings for the same type so let's look at how we could uh implement an ordering for a cat
00:23:06
for example so we have our data type which is a simple case classical cat
00:23:11
and we can then define um or ordering or simply um
00:23:18
creating a new instance for all of the trade or or
00:23:22
anonymous class in this case um and ordering folk at
00:23:27
that implements the method compare it's defined on the ordering crate
00:23:32
and provide implementation for it and when we have this cat ordering in school
00:23:39
we can then sort list of cats um
00:23:43
pretty um naturally so we could either pro caller sort of my thoughts and provide
00:23:50
ordering that we just defined or because the sort of method actually takes it implicitly
00:23:56
we can define it as an implicit where you intend to sort of method will pick up
00:24:02
the parameter automatic only to to define our own type classes there are several steps involved um
00:24:13
so the type just patton consists of type class itself which is basically
00:24:18
a trait like ordering that you've seen before that takes the type parameter
00:24:23
um then there are the type class instances um in the example before it would have been our cat ordering
00:24:29
and then we also have an interface to use the type class
00:24:35
and it's in many cases um there's something called
00:24:38
an enriched interface that will cover um in several minutes
00:24:42
so which basically i would us would allow us to define a method
00:24:47
for certain type and core that method on the type like it is defined
00:24:52
on the class itself like you're used to from start typing so let's uh
00:24:59
walk for a simple example of two implemented type class called describe herbal tea
00:25:05
describe although um has one single method call describe and
00:25:10
it's doing something rather simple so for any type he
00:25:15
it outputs um informal description of the type and
00:25:21
and the class so in this case so what do
00:25:24
we want to achieve um if you want to look if you look at the example and we have here
00:25:30
two data types um a cat and coffee and those data types
00:25:35
are completely unrelated so there is no stop typing hierarchy that connects them
00:25:41
and then we have two instances of our data type and in the end we would like to be able
00:25:46
to simply call our cat instance and call describe on
00:25:51
it like it's a method that's defined on the class
00:25:55
and also that's the second syntax that we are able to use so we could also
00:26:00
call the interface i call describe on it with any type
00:26:05
that we have an implementation for it so the first thing that we're doing is we define our trade
00:26:15
um which is the type class and it's so this is the simple
00:26:21
part um it's um basically just a trait that defines a type variable
00:26:26
and the method that you want to or the functionality that you
00:26:29
want to provide so as soon as we have that um the next
00:26:36
step is that we need to provide some instances for our data types
00:26:39
that we want to support so we could start by simply uh um
00:26:45
implementing the traits again for our own data types in this case we
00:26:50
have a cat and a coffee so we create you would use um
00:26:55
with the trade describe bubble and if we do that we
00:26:59
are able to call describe bubble and the methods with our
00:27:04
i'm very variables are instances so this works as expected
00:27:09
but it's not really a big benefit or it's a
00:27:12
a have a method called describe cat and one describe
00:27:16
coffee right so and there's also nothing really polymorphic about it
00:27:21
so how can we improve this code um let's start with the first attempt at an interface for using our
00:27:28
type class um so this object describes uh_huh is now
00:27:33
polymorphic function um with the piper on the t. v.
00:27:38
and it takes an element of t. v. and also
00:27:41
it's a second parameter we take it describe opal forty
00:27:45
and then i on this describe people we call the described my thought so this is actually
00:27:52
an improvement to record for we're now able to call to describe my thought with with different types
00:27:58
but it's a little bit uh tedious to every
00:28:01
time provide this describe bubble when we call describe method
00:28:06
um for this reason we could improve it further
00:28:09
and make to describe or um an implicit parameter
00:28:15
and now with ah updated version
00:28:19
we are able to call described described for any data type that we have an
00:28:24
describe opal instance in scope so since we're talking about
00:28:32
implicit slick let's take a short a teacher and have a
00:28:36
quick look at how implicit scopes works or where does
00:28:39
the compiler look for um implicit instances for our type classes
00:28:46
they're basically for different places so that compilers looking in the current school
00:28:52
of the project um program where we could define no implicit uh instances where yours
00:28:58
um it also looks in the companion object of the type to you so in our example
00:29:02
but would be kept or coffee and it also looks in the companion object of type class
00:29:08
or in places could be imported explicitly
00:29:12
so i'm not trendy imported simplest it's um
00:29:17
take a precedence over the implicit defines in a companion objects
00:29:23
so for this reason companion objects are a good place to put like default instances for your type classes
00:29:29
um if we think about ordering from before ours would would make total sense
00:29:35
to define um the most common ordering for integers in your companion object of ordering
00:29:41
um in in case that you need a special ordering
00:29:44
of numbers you could still over right that logic by providing
00:29:48
yeah on implicit uh instances i
00:29:53
also there is a a concept called context
00:29:55
bonds that makes i'm working with a implicit parameters
00:30:00
for type classes a little bit nicer so in many cases we don't really care about some
00:30:06
the name of the implicit parameter because we're only going to pass it to the next method that recording
00:30:12
so if we look at the description printer here um
00:30:16
this implicit parameter um the scrabble for to use not really used you're the only
00:30:22
um they only use for it is to pass it on to describe effort here
00:30:28
um and in this case we can make the code a lot a shorter and more readable
00:30:33
if we use a complex pond which basically um is to syntax that you see here
00:30:38
so you have type to you and the call on and describe people
00:30:43
and this is um does does the same as your butt off so
00:30:49
it says the tickle print you need to have a describe apollo for t. in scope
00:30:55
but it's not named and it will just be passed on to the to describe method here i
00:31:01
still if you use that syntax and uh you need to use the parameter inside of us thought
00:31:07
there's also the way to do this so if we look at
00:31:12
this a method here if we use the um context pond syntax
00:31:18
we can still uh summon the implicit parameter but using the implicitly
00:31:23
keyword which has a typo here okay so okay so our interface is
00:31:31
already looking quite nice but there is actually one more thing that
00:31:34
we can improve about it so if we look at our interface
00:31:38
um all that does describe my thoughts inside describe uh is delegating
00:31:43
the call to the describe method of the describe double um type clothes
00:31:48
this might not be a big problem in this example but if you have a lot of my thoughts
00:31:54
on your traits and you have to repeat it for every method inside
00:31:58
of your interface that's just what a plate that we can um avoid
00:32:04
so if you want to have an interface this basically the same as
00:32:08
the interface defined on the type clothes you can uh work around this repetition
00:32:16
by defining um and apply my thought that simply
00:32:20
um takes an implicit parameter for the prototype has
00:32:27
and returns that instance and when you do that um you're then
00:32:32
able to basic uh some on an instance off to describe of oh
00:32:36
for this type and call the method on it directly so we could
00:32:42
call describe for kept like to see hear these two lines are um but what you will see
00:32:49
more often is that it's used uh inside of methods that also take type parameters because then it's
00:32:55
much more a useful then putting that type in here directly
00:32:59
so if you have to sprint description i thought like you below
00:33:03
which uh also has a type parameter t. we can then say um
00:33:09
get to describe a four type t. one call describe on it i
00:33:17
yeah that's a short summary of the interface um that we just defined so
00:33:22
when we have templates parameter we can write an interface that then
00:33:26
works for any type to you that we have an implementation for
00:33:31
and but using the implicit instances um we
00:33:34
also can have multiple different uh implementations prototype
00:33:39
and choosing the implementation works by selecting the uh right implicit
00:33:44
instance that we want either by importing it or defining it
00:33:48
you know our current scope or so one more thing that we can enhance an
00:33:56
hour type was is that week if it's um and syntax that we used to
00:34:03
from a as a as if the method was defined on the object itself so
00:34:10
calling describe it can't describe it works but it doesn't look very natural or are nice
00:34:16
so what we ideally would like to have is
00:34:19
um to call describe on the cat or coffee itself
00:34:23
and this is possible by implementing an
00:34:27
implicit class and it's a this implicit class
00:34:33
basic away um takes a parameter of
00:34:37
our type t. and we can then um
00:34:41
whole described my thought on our intermediate class and by extending any well uh we're
00:34:49
also making sure that we don't have any run time overhead for creating this class
00:34:55
and when we do that and put it all together from example um we come up with a us
00:35:02
this solution so this is the implementation of the of the typecast pattern
00:35:06
um we we have to type class which is our trade with the type parameter
00:35:12
we have the interface um to to work with the with the functionality
00:35:19
and we need so um instances for the types that we want to support
00:35:23
and we can also provides a type in richmond to work more naturally with the with instances
00:35:35
so the good parts of the type just happen is that your or you know not creating any
00:35:41
hierarchy between possibly on related types because
00:35:45
had some coffee or not it's related by anything right um i except the
00:35:50
fact with that if we want to uh describe both of them so it's really
00:35:53
nice to to keep them on related and just implement the interface for both of
00:35:57
them um we can have multiple implementations per type type classes work for external code
00:36:05
and um we don't have to modify an existing code so if we
00:36:09
want to create a new functionality would just create a new uh type class
00:36:15
and implement your instances um somewhere in our code
00:36:19
but we don't have to modify any existing type classes or any existing data types
00:36:25
and also if we have a new data type type like talk for example we can also implement
00:36:31
any type class that we want um without modifying an existing code i hire
00:36:38
a downside of type plus um is that it's a little bit boilerplate team
00:36:43
um there are the same steps that you've seen a an example that need to be repeated again and again for
00:36:49
implementing type classes that they're um syntax improvements coming into
00:36:55
g. s. you might have seen in martins to not yesterday
00:36:59
and although it's possible to derive type classes
00:37:03
um the instances and there is a talk
00:37:07
on that later this afternoon by miles seven uh so if you're interested in the topic um
00:37:13
that's definitely a very um could talk that i will
00:37:16
also attend and it's one more downside of type classes is
00:37:22
if you need to um for it's like stay create this
00:37:28
stuff describe bubbles right because the types are um and related
00:37:32
so it's not very easy to do that in that case if this is like a um
00:37:37
major requirement of a court then you might want to think
00:37:41
if you if it's better to model it otherwise because of its
00:37:45
then maybe the types are related and you could go for supporting hierarchy um but
00:37:51
they're also at um um solutions to to solve this although they are quite involved and
00:37:57
again i bought a recommend a proposed by rob nor is i think it's the same one that i think than the previous slide
00:38:03
so um if you're interested uh than have to read um one one thing that
00:38:10
i would like to to show you is um soft upcoming features in a party
00:38:16
um which will basic any physically unable writing type classes with the
00:38:20
less why the plates and a nice uh syntax than at the moment
00:38:24
um so if we are if we um go back to our example from
00:38:31
the described above type class this is how it looks like eons got to
00:38:36
and a couple of things that are um not the nicest uh that's um we have
00:38:42
to define a lot of different employees it's here and it's gets a little bit and unreadable
00:38:48
um we have to define an implicit class just for the uh
00:38:53
just for the reason that we want to call this my thoughts um uh
00:38:57
on our type class and dotty actually provides a much nicer syntax for this
00:39:04
so if we look at their of todd example what i'm looking
00:39:08
dot e. m. t. i. um the new features that are used here
00:39:15
is that are described above train it now makes use of the new extension methods and text
00:39:21
but basically we um replaced as implicit classes so we can hear
00:39:26
before the method name we can put a parameter clause that
00:39:30
takes a parameter of team and this will enable us to um
00:39:34
call described on this on this type to you then i'm out
00:39:40
there is all the new syntax to not a half implicit in
00:39:45
several places with different uh meaning and there are now uh the keywords uh uh give them
00:39:51
to say that this uh it by my thought takes an implicit parameter of type describe double
00:39:57
and the their uh replaces based kill it uh implicitly that we have seen before
00:40:04
and so implements or create instances for type class
00:40:07
instead of defining implicit objects or implicit a well used
00:40:12
we can now create a dedicates for specific type class
00:40:19
and when we do that to use it uh stays unchanged but the code is um a lot more readable
00:40:26
and one thing that you still have to do with that
00:40:29
is of course uh implement instances for you all your type classes
00:40:34
and sometimes if it's a very generic implementation this
00:40:37
can also be um quite a lot of boilerplate
00:40:41
and for this reason thought people also provides a type plus a derivation
00:40:47
but this is a huge topic unless i suggested before
00:40:51
um there's a great talk about it this afternoon so yeah
00:40:56
thanks a lot and i hope you enjoy to talk i think we have a couple of minutes for questions
Conference Program
A Tour of Scala 3
Martin Odersky, Professor EPFL, Co-founder Lightbend
June 11, 2019 · 5:15 p.m.
8337 views
A story of unification: from Apache Spark to MLflow
Reynold Xin, Databricks
June 12, 2019 · 9:15 a.m.
1267 views
In Types We Trust
Bill Venners, Artima, Inc
June 12, 2019 · 10:15 a.m.
1569 views
Creating Native iOS and Android Apps in Scala without tears
Zahari Dichev, Bullet.io
June 12, 2019 · 10:16 a.m.
2232 views
Techniques for Teaching Scala
Noel Welsh, Inner Product and Underscore
June 12, 2019 · 10:17 a.m.
1296 views
Future-proofing Scala: the TASTY intermediate representation
Guillaume Martres, student at EPFL
June 12, 2019 · 10:18 a.m.
1157 views
Metals: rich code editing for Scala in VS Code, Vim, Emacs and beyond
Ólafur Páll Geirsson, Scala Center
June 12, 2019 · 11:15 a.m.
4695 views
Akka Streams to the Extreme
Heiko Seeberger, independent consultant
June 12, 2019 · 11:16 a.m.
1552 views
Scala First: Lessons from 3 student generations
Bjorn Regnell, Lund Univ., Sweden.
June 12, 2019 · 11:17 a.m.
577 views
Cellular Automata: How to become an artist with a few lines
Maciej Gorywoda, Wire, Berlin
June 12, 2019 · 11:18 a.m.
386 views
Why Netflix ❤'s Scala for Machine Learning
Jeremy Smith & Aish, Netflix
June 12, 2019 · 12:15 p.m.
5026 views
Massively Parallel Distributed Scala Compilation... And You!
Stu Hood, Twitter
June 12, 2019 · 12:16 p.m.
958 views
Polymorphism in Scala
Petra Bierleutgeb
June 12, 2019 · 12:17 p.m.
1113 views
sbt core concepts
Eugene Yokota, Scala Team at Lightbend
June 12, 2019 · 12:18 p.m.
1656 views
Double your performance: Scala's missing optimizing compiler
Li Haoyi, author Ammonite, Mill, FastParse, uPickle, and many more.
June 12, 2019 · 2:30 p.m.
837 views
Making Our Future Better
Viktor Klang, Lightbend
June 12, 2019 · 2:31 p.m.
1682 views
Testing in the postapocalyptic future
Daniel Westheide, INNOQ
June 12, 2019 · 2:32 p.m.
498 views
Context Buddy: the tool that knows your code better than you
Krzysztof Romanowski, sphere.it conference
June 12, 2019 · 2:33 p.m.
394 views
The Shape(less) of Type Class Derivation in Scala 3
Miles Sabin, Underscore Consulting
June 12, 2019 · 3:30 p.m.
2321 views
Refactor all the things!
Daniela Sfregola, organizer of the London Scala User Group meetup
June 12, 2019 · 3:31 p.m.
514 views
Integrating Developer Experiences - Build Server Protocol
Justin Kaeser, IntelliJ Scala
June 12, 2019 · 3:32 p.m.
551 views
Managing an Akka Cluster on Kubernetes
Markus Jura, MOIA
June 12, 2019 · 3:33 p.m.
735 views
Serverless Scala - Functions as SuperDuperMicroServices
Josh Suereth, Donna Malayeri & James Ward, Author of Scala In Depth; Google ; Google
June 12, 2019 · 4:45 p.m.
936 views
How are we going to migrate to Scala 3.0, aka Dotty?
Lukas Rytz, Lightbend
June 12, 2019 · 4:46 p.m.
709 views
Concurrent programming in 2019: Akka, Monix or ZIO?
Adam Warski, co-founders of SoftwareMill
June 12, 2019 · 4:47 p.m.
1974 views
ScalaJS and Typescript: an unlikely romance
Jeremy Hughes, Lightbend
June 12, 2019 · 4:48 p.m.
1377 views
Pure Functional Database Programming‚ without JDBC
Rob Norris
June 12, 2019 · 5:45 p.m.
6375 views
Why you need to be reviewing open source code
Gris Cuevas Zambrano & Holden Karau, Google Cloud;
June 12, 2019 · 5:46 p.m.
484 views
Develop seamless web services with Mu
Oli Makhasoeva, 47 Degrees
June 12, 2019 · 5:47 p.m.
785 views
Implementing the Scala 2.13 collections
Stefan Zeiger, Lightbend
June 12, 2019 · 5:48 p.m.
811 views
Introduction to day 2
June 13, 2019 · 9:10 a.m.
250 views
Sustaining open source digital infrastructure
Bogdan Vasilescu, Assistant Professor at Carnegie Mellon University's School of Computer Science, USA
June 13, 2019 · 9:16 a.m.
375 views
Building a Better Scala Community
Kelley Robinson, Developer Evangelist at Twilio
June 13, 2019 · 10:15 a.m.
245 views
Run Scala Faster with GraalVM on any Platform
Vojin Jovanovic, Oracle
June 13, 2019 · 10:16 a.m.
1342 views
ScalaClean - full program static analysis at scale
Rory Graves
June 13, 2019 · 10:17 a.m.
463 views
Flare & Lantern: Accelerators for Spark and Deep Learning
Tiark Rompf, Assistant Professor at Purdue University
June 13, 2019 · 10:18 a.m.
380 views
Metaprogramming in Dotty
Nicolas Stucki, Ph.D. student at LAMP
June 13, 2019 · 11:15 a.m.
1250 views
Fast, Simple Concurrency with Scala Native
Richard Whaling, data engineer based in Chicago
June 13, 2019 · 11:16 a.m.
624 views
Pick your number type with Spire
Denis Rosset, postdoctoral researcher at Perimeter Institute
June 13, 2019 · 11:17 a.m.
245 views
Scala.js and WebAssembly, a tale of the dangers of the sea
Sébastien Doeraene, Executive director of the Scala Center
June 13, 2019 · 11:18 a.m.
661 views
Performance tuning Twitter services with Graal and ML
Chris Thalinger, Twitter
June 13, 2019 · 12:15 p.m.
2003 views
Supporting the Scala Ecosystem: Stories from the Line
Justin Pihony, Lightbend
June 13, 2019 · 12:16 p.m.
163 views
Compiling to preserve our privacy
Manohar Jonnalagedda and Jakob Odersky, Inpher
June 13, 2019 · 12:17 p.m.
302 views
Building Scala with Bazel
Natan Silnitsky, wix.com
June 13, 2019 · 12:18 p.m.
565 views
Diversity and Inclusion Panel: Bring the Thunder!
Panel
June 13, 2019 · 2:30 p.m.
245 views
Asynchronous streams in direct style with and without macros
Philipp Haller, KTH Royal Institute of Technology in Stockholm
June 13, 2019 · 3:45 p.m.
304 views
Interactive Computing with Jupyter and Almond
Sören Brunk, USU Software AG
June 13, 2019 · 3:46 p.m.
681 views
Scala best practices I wish someone'd told me about
Nicolas Rinaudo, CTO of Besedo
June 13, 2019 · 3:47 p.m.
2707 views
High performance Privacy By Design using Matryoshka & Spark
Wiem Zine El Abidine and Olivier Girardot, Scala Backend Developer at MOIA / co-founder of Lateral Thoughts
June 13, 2019 · 3:48 p.m.
754 views
Immutable Sequential Maps – Keeping order while hashed
Odd Möller
June 13, 2019 · 4:45 p.m.
277 views
All the fancy things flexible dependency management can do
Alexandre Archambault, engineer at the Scala Center
June 13, 2019 · 4:46 p.m.
389 views
ScalaWebTest - integration testing made easy
Dani Rey, Unic AG
June 13, 2019 · 4:47 p.m.
468 views
Mellite: An Integrated Development Environment for Sound
Hanns Holger Rutz, Institute of Electronic Music and Acoustics (IEM), Graz
June 13, 2019 · 4:48 p.m.
213 views
Closing panel
Panel
June 13, 2019 · 5:54 p.m.
400 views
Recommended talks
GADTs in Dotty
June 14, 2019 · 4:41 p.m.
302 views