First of all, I apologize in advance if I sound argumentative. It's just
how main brain learns.
Alex, thanks for your thoughtful reply. Below is how I would do your Square
example in Java and Kotlin. Both examples combine data and logic and both
examples are fully *immutable*.
*Java*
public class Square {
private final float size;
public Square(float size) {
this.size = size;
}
public float getSize() {
return size;
}
public float getPerimeter() {
return size * 4;
}
public float getArea() {
return size * size;
}
}
*Kotlin:*
class Square(val side: Float) {
val perimeter: Float get() = side * 4
val area: Float get() = side * side
}
In an object oriented language, what would be the point be of having
> immutable data?
>
Same as in a functional language. I do it all day and every day. I have
written huge and useful components in Java and Kotlin and Scala without a
single mutation.
> 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.
*Conclusions*
Here is the original assertion from the Elm docs: "Elm encourages a strict
separation of data and logic, and the ability to say 'this' is primarily
used to break this separation. This is a systemic problem in Object
Oriented languages that Elm is purposely avoiding."
I have read the responses in this thread carefully and thoughtfully. None
of the answers addressed the question in my original question in a way that
satisfies my sense of logic.
So here are my conclusions:
*1. Immutability is a separate issue. *I only bring this up because many of
the replies in this thread brought up immutability*.* Immutability is not
really related to the issue we are discussing. But regardless, OO is
perfectly happy being immutable. I do it all the time. Immutability *is* a
problem with JavaScript. But not with Java, Scala or Kotlin or C# or most
OO languages. As demonstrated by the examples above.
*2. Combining data and logic is not a systemic problem in object oriented
programming.* I would argue that it is an advantage for some use-cases. I
have, for many years, been happily and successfully writing code that is
both immutable *and* combines data and logic.
*3. "this" is not a systemic problem with OO languages*. It *is* a systemic
problem with JavaScript, but that is another topic. Java and Scala all deal
with "this" quite nicely and predictably.
Checkout this example of a Card class (as in a Card game). It combines data
and logic. And uses "this" (implicitly, as is usually the case). And it is
completely immutable:
https://github.com/StokeMasterJack/bj1/blob/master/src/main/kotlin/bj1/Card.kt
Please look at this code and explain to me the systemic problem I am
missing.
This may sound like bikeshedding. But before I delve into a solution (in
this case, Elm forcing the separation of data and logic) I like to
understand the problem. And it appears that in this case, unless I am
missing something, the problem statement seems based on an incomplete
understanding of object-oriented programming languages (other than
JavaScript).
I may be wrong. I am open to changing my opinion if someone posts new
information I haven't considered.
Side note: here is more logical reason for forcing the separation of data
and logic: it lowers the surface area of the language, thus making it
easier to learn for beginners
--
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.
