Tim, I'm glad we're in agreement, but I confess I wasn't specifically replying to your message - just wanted to generally chime in to this discussion =)
I'm personally indifferent as to whether or not there should be some sort of automatic JSON functionality. I'm sure it could be done in a clean and focused way that wouldn't detract from anything else, but so far I haven't been bothered by the need to write explicit encoders/decoders (and I kind of like how it forces you to be very explicit about exactly what kind of JSON you create and accept). On Friday, 17 June 2016 22:21:42 UTC+10, Tim Stewart wrote: > > Yeah just to be clear to Ian, I absolutely agree that a general macro > system would be more trouble than it would be worth. It has a place in some > languages but would take away from the simplicity that Elm promises - and > increasingly delivers on. 0.17 was a big increment in that sense by making > interfacing with JS and the external world in general more approachable. > > I really was just hopping on the observation about JSON serialization and > pointing out it has been talked about. If a future release could alleviate > the currently somewhat cumbersome way of marshalling between JSON and Elm, > that would be another great increment. Something along the lines that Max > and Peter suggest would be awesome. > > I am impressed by Elm's conservative approach in not granting developers > (or DSL authors who might want macros) everything they might want, whilst > still giving them what they need. In this case, not getting macros but > getting compiler generated serialization would be a great outcome. > > > > On Friday, June 17, 2016 at 4:48:42 PM UTC+10, Peter Damoc wrote: >> >> 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.
