search

dcastro / dcastro.github.io

https://diogocastro.com
Other
6 stars 1 forks source link

Typeclasses in perspective #2

Open dcastro opened 6 years ago

dcastro commented 6 years ago

Comments left here will be displayed on this blog post: https://diogocastro.com/blog/2018/06/17/typeclasses-in-perspective/

aaronj1335 commented 5 years ago

Thanks for the great write-up; I learned a lot! I'm still pretty new to static-typing, so I find stuff like this really helpful.

Is my understanding correct that the Java example in the "Conditional implementation" section:

class List<A> implements Encodable {
  public Json toJson() { ... }
}

While this isn't possible in Java, it's essentially what Kotlin extension functions allow? So that means that while Kotlin's type system solves the "Extensibility" shortcoming mentioned in this article, the other four still remain?

lindig commented 5 years ago

Very clear presentation!

dcastro commented 5 years ago

@aaronj1335, @lindig: Thank you!

@aaronj1335: I'm not familiar with Kotlin, but from scanning that link, Kotlin's extension functions look a lot like C#'s extension methods, which are just syntactic sugar for static methods: x.f() gets compiled to f(x).

These would allow you to "add" a toJson method to lists, yes, but it wouldn't allow you to abstract over all "encodable things". E.g., you would still not be able to pass lists into def postAsJson[A <: Encodable](body: A): Future[HttpResponse].

Even though they are convenient, extension functions/methods are not a means of abstraction.

aaronj1335 commented 5 years ago

Ah, that makes sense — a toJson method on a type isn't as helpful if you need to write stuff that accepts that specific type in order to call it. Thanks!