Thank you so much for all the replies, especially to Max for his insights on decisions made in his animation library.
I feel like I'm a bit closer to understanding the issues here, but I still have some fuzzy edges: Serialization: If I'm manually serializing my model to persist somewhere, I can easily skip over an animation property. But what about the stuff demo'd in 0.18? That's automatically serializing my model while debugging. Does anyone know if I'll be unable to use that sort of tooling because I have a function in my model or message? Equality: Similar to serialization, is this just a matter of me having to be smarter when doing manual optimizations that look at model equality? Or is there something in the runtime/compiler that is going to break or be less optimized as a result? I suppose some of this is trying to predict the future. It just makes me nervous to hear from Evan "definitely don't do this thing" but not fully understand the implications of selectively ignoring that advice by pulling in one of the really nice animation libraries. On Tuesday, October 4, 2016 at 10:19:51 PM UTC-5, Max Goldstein wrote: > > Hi, I'm the author of the second library you mentioned. It's natural to > represent easing functions as, well, functions. > > One way to avoid this would be to change (or supplement) > elm-community/easing-functions > <https://github.com/elm-community/easing-functions> to contain a big > union type of all the easings possible. Then we could have a function that > turns that type into an easing function. The animation models would contain > a reference to this EasingDescription rather than the function itself. > > There are some major downsides to this approach, not counting the work > involved and library clutter. First, consumers of the animation library > will have to know about the EasingDescription; it couples the two libraries > and causes the abstraction to leak. Second, animations will only be able to > use easing functions that have descriptions, not any easing function they > like. Finally, my library allows animations to be undone or retargeted, > which involves working with the easing function in ways beyond the > description. > > So, a better approach might be to sample the easing function provided > (perhaps 100 times in 0..1) and use linear interpolation between these > samples. Many samples gives a more accurate animation but consumes more > memory. This approach also means that retrieving an easing function from an > animation will be inexact. > > Even so, until someone tells me that everything will explode if you have > functions in your model, I'm going to sit tight. > -- 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.
