-
Notifications
You must be signed in to change notification settings - Fork 1.1k
[Documentation] Trying to rewrite typeclasses-new #8147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello, and thank you for opening this PR! 🎉
All contributors have signed the CLA, thank you! ❤️
Have an awesome day! ☀️
```scala | ||
assert(3 == List(1, 2).combineAll) | ||
``` | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this, it's a lot more with the style of the rest of the documentation. If you apply the same style to the Functors and Monads section this will be really nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK I'm not sure I have enough knowledge to re-write the Functor/Monad part in the same fashion (you need to understand properly to explain properly) but I will definitely give it a try.
If I'm struggling I'll ping you, so that you know you can merge this as is (best if the ennemy of good ;) ). But that's worth trying.
I added parts re. functors and monad but left apart the Reader Monad. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for taking the time to write this tutorial. I think it will help people a lot. I've just made a few suggestions concerning correct use of definitions.
Co-Authored-By: Jamie Thompson <[email protected]>
Co-Authored-By: Jamie Thompson <[email protected]>
Co-Authored-By: Jamie Thompson <[email protected]>
Co-Authored-By: Jamie Thompson <[email protected]>
Co-Authored-By: Jamie Thompson <[email protected]>
Co-Authored-By: Jamie Thompson <[email protected]>
…hism Co-Authored-By: Jamie Thompson <[email protected]>
Co-Authored-By: Jamie Thompson <[email protected]>
Co-Authored-By: Jamie Thompson <[email protected]>
Co-Authored-By: Jamie Thompson <[email protected]>
…asses-new # Conflicts: # docs/docs/reference/contextual/typeclasses-new.md
… doc/rework-typeclasses-new
Ready for review / merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you will need to change the filename to drop the -new
now
I have read that maybe we'll go back to |
I renamed |
|
||
The definition of a _typeclass_ is expressed via a parameterised type with abstract members, such as a `trait`. | ||
The main difference between object oriented polymorphism, and ad-hoc polymorphism with _typeclasses_, is how the definition of the _typeclass_ is implemented, in relation to the type it acts upon. | ||
In the case of a _typeclass_, its implementation for a concrete type is expressed through a `given` term definition, which is supplied as an implicit argument alongside the value it acts upon. With object oriented polymorphism, the implementation is mixed into the parents of a class, and only a single term is required to perform a polymorphic operation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this part about comparing to OOP could be moved to the start
@aesteve What do you think about moving the comparison with OOP polymorphism? |
Hello. Mixed feelings about this. We could move the OO comparison at start (and remove the part about "it's just traits" or move it at the end) indeed. For people who just want "I know, I know, just show me the syntax" a big intro with OOP comparison sounds quite "heavy", for people who don't know anything about typeclasses AND are familiar with OOP, it's accurate to have it at the start. Honestly, that's quite a big "I don't know" for my part. Do you want me to move it? Or should I give you access to my fork so that you can change it, or ? |
Maybe there can be an "aside" or some sort of box that can be skipped, my main concern was just that putting it at the very end seemed maybe out of place |
I think in balance we would like to get this through, so If the wildcard type arguments are updated to use |
Oh sorry, I've missed some changes to upstream. Can you point me at the change, please? |
Sure ok, have a look at http://dotty.epfl.ch/docs/reference/changed-features/wildcards.html |
Waw, didn't know about that :) Should be ok now! Re. the Thanks. |
Great, thank you :) |
This is now published |
When first looking at this part of the doc, it wasn't completely clear to me.
For example:
I didn't really understand if extension methods and context bounds are needed to define a type class or if they simply help using them.
Simply using "whose" here helped me a bit. "Typeclasses are traits" (ok, so they're some abstract definition, fine), "whose implementation is" (oh ok, so this is the way of implementing the trait that differs, fine).
And finally, since the
object Monoid
with itsapply
method confused me a bit (is this part of a typeclass declaration?) I chose to first define the typeclass and use it without the object usingsummon
, then add the object and removesummon
.Note that this is a "parti-pris" to rewrite the doc in a more "progressive" (or "tutorial") manner. And this may not be desirable feel free to tell me. That's not because I find it easier to understand this way, that everyone will...
Thanks for your reviews.