[docs] Add a blog post about type classes #4913
Conversation
| ```scala | ||
| val clients1 = IO(Vec(4, Flipped(new ArbiterClient))) | ||
| val arbiter1 = Module( | ||
| new GenericPriorityArbiter(4, new ArbiterClient)(_.request, (c, g) => c.grant := g) |
There was a problem hiding this comment.
not sure if it might be helpful to show a version of this with the arguments explicitly called out by name. Generally when showing big code blocks it can be helpful to try to draw people's attention to the most relevant bits. Then we could say something like "we can make this shorter / more scala-y by writing it like this :... but it's still pretty clunky"
| Effectively, we have taken the two arguments to the arbiter and turned them into methods on the type class. | ||
| This looks similar to the proposed object-oriented version of `Arbitrable` above, but note how it is parameterized by the type of the client and accepts the client as an argument. | ||
|
|
||
| We can then provide instances of this type class for specific types. For example, for `ArbiterClient` and `Decoupled`: |
There was a problem hiding this comment.
| We can then provide instances of this type class for specific types. For example, for `ArbiterClient` and `Decoupled`: | |
| We can then define subclasses (or implementations?) of this type class for specific types. For example, for `ArbiterClient` and `Decoupled`: |
Why do we call this an "instance". This is just a class definition. one would have to instantiate it to make it an instance. I think later we will make default implicit instances, but we haven't done that yet, right?
| At least we aren't repeating logic anymore, instead we get to just refer to the type class instance. | ||
|
|
||
| However, we can do even better. | ||
|
|
There was a problem hiding this comment.
I'm sort of wondering why we even need to mention "type class" at all, up until this point. Like you could describe the pattern first, then say "by the way, this pattern of making a trait that is parameterized by type, and all its methods are parameterized by type, we call 'type class'"
There was a problem hiding this comment.
Yeah I think that's a good suggestion.
| ``` | ||
|
|
||
| This is equivalent to the previous definition, but is more concise. | ||
| Note that unlike the version with the implicit argument, this one does not bind a variable name for the implicit argument. |
There was a problem hiding this comment.
is this really relevant for the blog post? is this something people are going to need to do?
| implicit def decoupledArbitrable[T <: Data]: Arbitrable[DecoupledIO[T]] = ... | ||
| } | ||
| ``` | ||
|
|
There was a problem hiding this comment.
Or if you are defining a new type you want to make arbitrable, you could include it in the package object for that type
Isn't this the more common case? Can we show it?
|
not sure what the milestone should be, when did we introduce the blog to the website |
Co-authored-by: Megan Wachs <[email protected]>
jackkoenig
force-pushed
the
jackkoenig/arbiter-typeclass
branch
from
40d7508 to
29ad289
Compare
Contributor Checklist
Type of Improvement
Desired Merge Strategy
Release Notes
Reviewer Checklist (only modified by reviewer)
3.6.x,5.x, or6.xdepending on impact, API modification or big change:7.0)?Enable auto-merge (squash)and clean up the commit message.Create a merge commit.