Skip to content
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

Add possiblity to specify default values for for record fields: #231

Closed
wants to merge 611 commits into from

Conversation

tolysz
Copy link
Contributor

@tolysz tolysz commented Dec 8, 2014

Say we want to derive:

data GGResult = GGResult
  { _ggrtPartialMatch       :: Bool
  } deriving (Show, Typeable)

deriveJSON
   defaultOptions
    { fieldLabelModifier = fromCamel 5
    , fieldsWithDefaults = [ ("partial_match", [| False |]) ]
    }
   ''GGResult

Now whenever parser was expecting field "partial_match" inside JSON file but it is not there, the parser will not fail but return a value False.

Clark Gaebel and others added 30 commits October 25, 2012 15:52
Added an instance for the 'Fixed' class.
parseJSON for the variations on ISO-8601 dates as listed in ECMA-262.
Add functions for inspecting Values
Added eitherDecode and eitherDecode'
Add elaborate guide to Data.Aeson's Haddock documentation
De-emphasize working directly with the Value type as this is not the
common (or recommended) way to use the library, but still include
documentation on how to use it when it's called for.

Since the documentation on using generics is documented in the FromJSON
and ToJSON classes, refer to that documentation instead of only
documenting one method (which is not the preferred method anymore with
default signatures I believe).
Improve introductionary documentation
Add support for specifying how to encode datatypes in Data.Aeson.TH
bos and others added 23 commits May 15, 2014 09:28
--HG--
extra : amend_source : d48e612e53488f41b0d6f2ceb4395978b48d411d
--HG--
extra : amend_source : aa3ad961a2c62e2948ee0e213615c01ac002b42c
This is more portable between compilers as well as between variants on GHC (ex: HaLVM is building off of head so GHC appears as 7.8.3 while TH is 2.10).
Data.Aeson.Types.Instances: fix UTCTime for years outside of [0, 9999]
Modernizing the TH example.
Export 'camelTo' function and fix its tests
Say we want to derive:

    data GGResult = GGResult
      { _ggrtPartialMatch       :: Bool
      } deriving (Show, Typeable)

    deriveJSON
       defaultOptions
        { fieldLabelModifier = fromCamel 5
        , fieldsWithDefaults = [ ("partial_match", [| False |]) ]
        }
       ''GGResult

Now whenever parser was expecting field "partial_match" inside JSON file, will not fail but return a value `False`.
@tolysz
Copy link
Contributor Author

tolysz commented Dec 8, 2014

Hi,
This pull is a effect of having to parse some JSONs where the default value is sometimes omitted, and it is well defined for a given format.

One can specify new value inside Oxford brackets [| value |]
I hope it could be reviewed and pulled in one way or another.
Regards.

@basvandijk
Copy link
Member

Thanks, I like the feature!

Is there a possibility you can also build this into the GHC.Generics decoders?

@tolysz
Copy link
Contributor Author

tolysz commented Dec 9, 2014

I did not play with Generics, but would have doubts if one can only specify values for one field of constructor (or just one constructor) and having all other parts derived. Or override only some patterns or generated implementations. If only we had something like [ http://en.wikipedia.org/wiki/Pattern_calculus ].

@basvandijk
Copy link
Member

Oh I see that the ExpQ in fieldsWithDefaults :: [(String, ExpQ)] doesn't map directly to GHC.Generics.

Can't we have an interface which is TH agnostic? For example:

fieldsWithDefaults :: [(String, Dynamic)]

Then in the GHC.Generics decoder we check for missing fields, match them against the fieldsWithDefaults and convert the resulting Dynamic to the desired type.

If this will be a TH-only feature we should clearly document that because currently both the GHC.Generics and TH encoders behave identically.

@tolysz
Copy link
Contributor Author

tolysz commented Dec 10, 2014

If we mix TH + Generics it still works

data GGResult = GGResult
 { _ggrtPartialMatch       :: Bool
 } deriving (Show, Typeable, Generic)

instance FromJSON GGResult where
  parseJSON = genericParseJSON
     (defaultOptions
      { fieldLabelModifier = fromCamel 5
      , fieldsWithDefaults = [ ("partial_match", [| False |]) ]
      })
instance ToJSON GGResult where
  toJSON = genericToJSON
     (defaultOptions
      { fieldLabelModifier = fromCamel 5
      , fieldsWithDefaults = [ ("partial_match", [| False |]) ]
      })

This TH will complain at the compile time if there is a type mismatch. I am not so well wersed in Dynamic or Generics to know, how they behave.
I can easily accept anything convert False or [| False |]; my codebase is too small to care. My only problem is how it will scale in the future. (currently I would +1 the TH)

I will look later how to do it with Dynamic, so it is gone once the code is compiled.

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.

None yet