It’s not valid Java for e.g. Lists, Maps, Strings or any programmer-defined classes.
Same with operator overloading.
myVectorA + myVectorB is not valid Java, but it is valid OOP in e.g. Python or C++. And this kind of syntactic sugar reduces verbosity enourmously, while still being OOP.
If you have ever worked in e.g. Python, Groovie or Kotlin you notice quickly how non-verbose OOP can be.
It seriously is just Java.
And Javas insistance on having you wrap non-OOP things in fake OOP constructs (e.g. static methods, which are just functions in modules, but you have to uselessly abuse classes as modules) isn’t helping either.
Compare:
x.field[5]with
x.getField().get(5)Both are exactly the same level of OOP, but the Java version is roughly twice as long. Add operator overloading to the mix and it becomes much worse:
x.getField().get(5).multiply(6).add(3)vs
x.field[5] * 6 + 3All this has nothing to do with OOP, but with syntactic sugar that is applied.
As I said, the convention is now x.field() not x.getField()
What language are you comparing against here? x.field[5] is valid Java if field is a public array, but that’s not OOP, at least not in a pure sense.
It’s not valid Java for e.g. Lists, Maps, Strings or any programmer-defined classes.
Same with operator overloading.
myVectorA + myVectorBis not valid Java, but it is valid OOP in e.g. Python or C++. And this kind of syntactic sugar reduces verbosity enourmously, while still being OOP.If you have ever worked in e.g. Python, Groovie or Kotlin you notice quickly how non-verbose OOP can be.
It seriously is just Java.
And Javas insistance on having you wrap non-OOP things in fake OOP constructs (e.g. static methods, which are just functions in modules, but you have to uselessly abuse classes as modules) isn’t helping either.