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.
--
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.
