Re: [elm-discuss] Building a Store without boilerplate
Thanks for your elm-sapling example, that's an idea that I hadn't considered, I think it falls into approach (2) that I mentioned above. > I don't think that's possible. I have noticed that Haskell has solutions for this problem e.g. https://github.com/yesodweb/persistent. In that case it's using Template Haskell which I'm not familiar with but appears to be a meta programming framework for Haskell. Elm doesn't support anything like this natively which is why I was considering approach (3) using an external tool to do code generation. Aside from Haskell there's also examples of persistence frameworks with other statically typed languages such as Java and Scala, in those cases introspection is available so solutions tend to lean on those. On Monday, 30 January 2017 12:03:07 UTC+1, Peter Damoc wrote: > > > > On Mon, Jan 30, 2017 at 12:17 PM, Oliver Searle-Barnes > wrote: > >> # Building a Store without boilerplate >> > > I don't think that's possible. > Elm is a static language and what you seam to want is dynamic behavior. > > The practical way to solve this is to ferry type information and use that > type information to generate the dynamic behavior. > In Elm, this is done with the help of Json.Decode/Json.Encode > > This way, you can take a concrete Elm type, convert it to a generic type > like Value or String, do something dynamic based on the info you encode in > this generic type, get a generic result back and convert the result back > into some concrete Elm type. > so you can have something like: > > doSomethingDynamic : a -> (a -> Value) -> Decoder b -> b > doSomethingDynamic payload encoder decoder = > ... > > Have you seen how I have approached the issue in the exploration bellow? > https://github.com/pdamoc/elm-sapling > > > -- > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Building a Store without boilerplate
On Mon, Jan 30, 2017 at 12:17 PM, Oliver Searle-Barnes wrote: > # Building a Store without boilerplate > I don't think that's possible. Elm is a static language and what you seam to want is dynamic behavior. The practical way to solve this is to ferry type information and use that type information to generate the dynamic behavior. In Elm, this is done with the help of Json.Decode/Json.Encode This way, you can take a concrete Elm type, convert it to a generic type like Value or String, do something dynamic based on the info you encode in this generic type, get a generic result back and convert the result back into some concrete Elm type. so you can have something like: doSomethingDynamic : a -> (a -> Value) -> Decoder b -> b doSomethingDynamic payload encoder decoder = ... Have you seen how I have approached the issue in the exploration bellow? https://github.com/pdamoc/elm-sapling -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Building a Store without boilerplate
# Building a Store without boilerplate The app that I’ve been building has a Store abstraction which is built on top of elm-phoenix (websockets). Typical methods in the API are: Store.addProject projectAttributes store Store.renameProject projectId name store Store.deleteProject projectId store Store.getProjectUsers projectId store # relationship traversal The Store also handles latency compensation, so that for instance when you add a project it appears to the client that it has been added successfully even before a message has been sent to the server. Once the server confirms the operation is then confirmed/rejected in the client. While I'll happy with how the Store works, it does involved writing an absolute ton of boilerplate code. Every single method in the Store API needs to be hand written at every layer, updating the Store's internal model, the latency compensation and the serialisation. --- So the question is, in a statically typed language, with no introspection how would one go about avoiding this duplication? The two possibilities I've considered so far are: 1) Somehow do it in Elm, I'm struggling to see how it's possible, this would be my preferred option though :) 2) Define everything dynamically inside the Store, i.e. use Dicts everywhere instead of static types. Then provide the Store with a mapping which takes care of translating between the static and dynamic structures. Having to forgo static types is obviously disappointing with this route. 3) Code generation - lots of options here, could be inline macros in the Elm code, a custom DSL or code defined in another language. How would this sort of problem typically be solved in an ML language? Has anyone tried something similar in Elm? -- 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.
