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

Document automatic derivation more completely #27

Open
travisbrown opened this Issue Aug 11, 2015 · 1 comment

Comments

Projects
None yet
2 participants
@travisbrown
Member

travisbrown commented Aug 11, 2015

circe's automatic derivation module provides some interesting (and I think unusual) functionality that's barely documented right now, including incomplete case class instances and patch instances.

I want to create a new README under the generic directory that describes this functionality more completely.

@vkostyukov

This comment has been minimized.

Show comment
Hide comment
@vkostyukov

vkostyukov Aug 11, 2015

Collaborator

👍 From my understanding, the generic pacakge is a killer feature of circe. It somehow defines a new (and awesome) approach of dealing with JSON encoding/decoding. We should spread the world about it!

Collaborator

vkostyukov commented Aug 11, 2015

👍 From my understanding, the generic pacakge is a killer feature of circe. It somehow defines a new (and awesome) approach of dealing with JSON encoding/decoding. We should spread the world about it!

@travisbrown travisbrown added the ready label Aug 13, 2015

crispywalrus pushed a commit to flyingwalrusllc/circe that referenced this issue May 16, 2016

A mostly clean room reimplementation of Or.
Implements feedback from #11.  Specifically:
1. LOr and ROr move to `Or.LeftOr` and `Or.RightOr`.
2. Constructors are still public, but `left` and `right` preserved in
   `OrFunctions` to infer `Or`.  Use what you like.
3. Only the Scaladoc is ripped from Scalaz.

Also tries to adhere to the emerging consensus on #27.

Preliminar benchmarking showed monomorphism is faster than polymorphism,
and that implementing other operations using fold/bimap is immeasurable.
The second finding is dubious with respect to allocations.  If someone
can prove these guilty via benchmark, we can revisit.

I'd like to add tests after #29 happens.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment