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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
