Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@afsalthaj
Copy link
Contributor

The module currently makes use of DeriveGen; allowing users to call DeriveGen[Refined[String, NonEmpty]] to get a Gen[Refined[String, NonEmpty]]

Gen.weighted(Gen.char(48, 57) -> 10)

private val whitespaceChars: Seq[Char] =
(Char.MinValue to Char.MaxValue).filter(_.isWhitespace)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh. May be move these to Gen companion object.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. πŸ‘

Copy link
Contributor

@adamgfraser adamgfraser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great!

In addition to just more instances, the biggest thing I see here is we may want to split out the Refined support from the automatic derivation. Right now these are bundles together so it is great if you want to automatically derive generators for refined types, but if you want to manually put more complex ones together from the simpler ones to build in some custom logic it is a little clunky because you have to unpack the DeriveGen instances.

I think we could have the same functionality here and make it more flexible if we first defined a set of constructors for Gen values for refined types and then used these to construct DeriveGen instances for those types.

I will merge this now and open separate issues to follow up on this.

@adamgfraser adamgfraser merged commit 2769933 into zio:master Jan 25, 2021
@afsalthaj
Copy link
Contributor Author

afsalthaj commented Jan 25, 2021

Thanks @adamgfraser

@pierangeloc and myself had a discussion about separating out the logic to only return Gen and then have separate refined module that later lifts them to refined types. But it suddenly became a bigger change for an initial
solution when I tried this here (master...afsalthaj:test_implicit_refined ). Hence we thought of keeping it small and getting your early feedback.

Thanks for merging. Really looking forward to use the module in production.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants