# Parameterize all the types! **URL:** \ **Category:** Outreach\ **Created:** [July 23, 2020, 1:38pm UTC](https://forum.canton.network/t/parameterize-all-the-types/906 "2020-07-23T13:38:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [July 23, 2020, 1:38pm UTC](https://forum.canton.network/t/parameterize-all-the-types/906/1 "2020-07-23T13:38:23Z")
I’ve recently seen [this nice talk](https://www.youtube.com/watch?v=BHjIl81HgfE) on the value of adding type parameters by DA’s own @StephenCompall. As a developer who generally prefers to keep things fairly concrete, this talk made me think a lot about the value of abstraction using an expressive type system. In particular, I see a lot of value in abstracting over details that you don’t want to test for in a specific situation. It simplifies testing and allows you limit using unnecessary tools or possibly some brittle hack. I usually like to not abstract in business logic data types because I tend to get lost with `A`s and `T`s. I find it difficult to understand the meaning of something if I can’t anchor it to something I can clearly understand. To go back to the example in the talk, why is this `WebPage` parameterized over something? What is this `A` floating around? When working with values, it’s usually a recognized good practice to give bindings and variables a telling name (unless you’re using a widely-recognized shortening in a clear context), so why not adopting the same attitude towards type parameters? Is there a good reason to have a `WebPage[A]` over a `WebPage[Content]`? Probably ergonomics, as handling types in most languages is a second-class citizen. I’m seeing more and more of a push in a direction where there’s little difference between using types and values (e.g. I like how Scala 3 will have named type parameters and there’s a proposal to add them to TypeScript). Have a look at the talk if you wish, I’d love to get your opinion on it. ---
**Author:** ![Leonid\_Shlyapnikov](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_shlyapnikov/32/241_2.png) [@Leonid\_Shlyapnikov](https://forum.canton.network/u/Leonid_Shlyapnikov)\ **Post date:** [July 23, 2020, 6:40pm UTC](https://forum.canton.network/t/parameterize-all-the-types/906/2 "2020-07-23T18:40:55Z")
If interested in another real life example, please have a look at the JSON API domain: > E.g. if we did not have `LfV` type parameter in `CreateCommand`, we would have ended up with 4 different classes representing `CreateCommand` with `payload` in different stages of processing, instead we can just do: - `CreateCommand[String]`, - `CreateCommand[JsValue]`, - `CreateCommand[LfValue]`, - `CreateCommand[ApiValue]` You can guess who insisted on introducing the type parameters in the JSON API domain 🙂. But yeah, good talk! ---
**Author:** ![SamirTalwar](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/samirtalwar/32/374_2.png) [@SamirTalwar](https://forum.canton.network/u/SamirTalwar)\ **Post date:** [August 14, 2020, 1:21pm UTC](https://forum.canton.network/t/parameterize-all-the-types/906/3 "2020-08-14T13:21:37Z")
I finally watched this talk and found it quite inspiring. It’s a great reminder that we can use the type system to constrain far beyond "this is an `Integer`". I’m not sure I’d use this technique when there really is only one possible type to insert, as I think the drawbacks of the more complicated type signatures would probably outweigh the upsides of the extra proofs. However, when there’s a possibility of more than one type, especially when we have multiple stages of parsing/transforming as detailed in the video and by @Leonid_Shlyapnikov above, I think it’s an excellent idea. ---
**Author:** ![Stephen](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stephen/32/102_2.png) [@Stephen](https://forum.canton.network/u/Stephen)\ **Post date:** [August 31, 2020, 10:38pm UTC](https://forum.canton.network/t/parameterize-all-the-types/906/4 "2020-08-31T22:38:08Z")
Glad you all found it interesting. I wish that languages would make type abstraction “cheaper” lexically, so to speak, so the costs @SamirTalwar mentions would not be so painful in some of the interesting but complex cases. If your choices are introducing a type parameter and introducing a mocking framework, surely you have only one choice, right? 🙂