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 [email protected].
For more options, visit https://groups.google.com/d/optout.
