-
Notifications
You must be signed in to change notification settings - Fork 43
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
Possible API Changes #11
Comments
Additionally, things like property/index testing and default values would be nice. |
With the signature parse :: forall a. (ReadForeign a) => F Foreign -> F a
parse = runV invalid read
data TestData = TestData Number Number Number
instance readTestData :: ReadForeign TestData where
read o = TestData <$> parse (o .: "foo")
<*> parse (o .: "bar")
<*> parse (o .: "baz") If you make it (.:?) :: forall a. (ReadForeign a) => F Foreign -> String -> F a
(.:?) obj k = runV invalid (\x -> x .: k) obj
instance readForeign :: ReadForeign Foreign where
read = pure
data TestData = TestData Number Number Number
instance readTestData :: ReadForeign TestData where
read o = TestData <$> (o .: "foo" .:? "nested")
<*> (o .: "bar")
<*> (o .: "baz") Which relates back to #8 |
(I have implemented this library using |
I've mocked up another version here: https://github.com/paf31/purescript-foreign-experimental Having tried pretty hard to get the applicative validation to work with a decent API, and without resorting to invalid |
I've wondered for a while whether it would be a good idea to rethink the API for this module. Given that I'm about to write about it for the book, it's probably a good time to raise my concern.
What if we changed the API as follows:
V
instead ofEither
.The text was updated successfully, but these errors were encountered: