On Sun, Jul 23, 2017 at 1:39 AM, Dave Ford <df...@smart-soft.com> wrote: > > It's not that OOP is bad, but it encourages mutation >> > OOP does not encourage nor discourage mutation. Java, Kotlin, Scala and > OCAML all *allow* mutation. Kotlin, an OO language that I use a lot, > actually *discourages* mutation. But regardless, my question was not > about immutability. It was about combining data and logic. >
I do not know Kotlin but all other OOP languages I've used allowed passing an object to a function and potentially having that object be mutated by that function. Maybe "encourage" is the wrong word here but this is an affordance that will be used. In any case, from what I remember from the discussions around object oriented programming around this list, mutability was the key feature that was brought forward as a source of problems that Elm avoids. It was linked to state in objects getting out of sync in certain contexts and to the fact that functions lose their purity. Another issue is the one you mentioned about the surface area of the language. Implementing OOP features would require permanently and irreversibly making the type system and the language more complex. The topic of typeclasses (one of the options) has been raised several times. It has been promised at one point as a feature that the language will gain in time but.... years passed and the topic got shelved. Outside of these two topics (immutability & complexity of the language) I don't remember seeing arguments for problems brought on by joining data and behavior together. I am interested in the topic of web components (I believe that Elm could benefit greatly from embracing this standard). I've even went as far as to implement a web components system in Elm (with the help of a little bit of Native code) and the only real argument against it that I remember is the argument of mutability. I even tried to implement a mutability-as-service component in order to try to see if this is possible. I failed. Still... the intuition of some of the senior developers of Elm is that this would be possible and that all the nice guarantees of Elm would fly out the window. This is the main reason I pointed to immutability. I think the complexity of the language issue is unavoidable but one can avoid the problems generated by mutability by having an immutable way of joining data and behavior (the FauxO system I hinted towards being one of the ways). I too would be very interested in seeing any kind of argument against joining data and behavior outside of these two main ones (immutability and complexity of the type system). -- 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.
