It's not a horrible idea to have encodeUser/decodeUser but why not go one step further and have an internal typeclass like serializable that would only be used in the Json libraries. Also, pick a standard encoding for the UnionTypes so they can become serializable as well. This will allow for compiler time errors if you try to serialize something that is not serializable and would simplify the handling of Json tremendously and would get rid of one of the silliest parts of Elm.
On Fri, Jun 17, 2016 at 7:38 AM, Max Goldstein <[email protected]> wrote: > I think Ian makes some great points and Iargely agree with him. I like > that Elm is actually less to learn than React, Ember, etc, once you factor > in ES2015 and JSX/handlebars and all the other stuff. > > However, automatically derived JSON decoders are something I could > potentially support. They seem to crop up a lot, and in application rather > than library code (i.e. Random generators and Producers can hide the > boilerplate behind a library but JSON can't be similarly carpeted over). > There's also some precedent here with type alias of record types. I think a > minimally obtrusive proposal would be no extra syntax, just some extra > functions defined implicitly by a type alias. Example: > > type alias User = { name : String, id : Int } > > defines the type User and also the function User : String -> Int -> User. > It's not a horrible idea to have it also define encodeUser : User -> > Json.Value and decodeUser : Decoder User. If the type alias isn't JSON > serializable, then nothing happens. If the programmer defines > (en|de)codeUser herself, then the generated versions disappear. > > -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
