On Thu, Nov 10, 2016 at 10:49 PM, Max Goldstein <[email protected]> wrote:
> What I meant was, Elm needs to choose differently from Haskell, at least > some of the time, or else there wouldn't be a reason for it to exist. It's the Object Oriented Programming. More precisely, the "fixed number of operations, unbounded number of implementations” that Martin Odersky talks about here <https://www.youtube.com/watch?v=Dxzbwq45tUA&feature=youtu.be&t=170>. It's not that one cannot do that in Elm it's that it can be very cumbersome (as it is with the X.map). Just imagine how cumbersome would be to have to use a different function everywhere you use a toString now. Evan said: > I consider it extremely bad practice to mix your data and your logic, and > as far as I can tell, that is the sole purpose of this and self If one has in mind mutations when looking at mixing data and logic, then yes, that is a Bad Thing™ but objects don't have to be mutable. (e.g. the strings in python) Maybe something like the FauxO that Gary Bernhardt mocked in his talk Boundaries could work for Elm. Anyway, I'm not asking for anything here. I am aware that this is a complex topic with the potential to produce such a radical change as to feel like a different language. In the mean time, I have found a way to do the OOP that I need in Elm via the webcomponents approach. It is using JS to glue together the data and the logic and to abstract it nicely in the interface provided by elm-html. It's cumbersome and I still need to figure out some things around tooling but, at least I'm not blocking on language features. :) -- 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.
