• Square Singer@feddit.de
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    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 + 3

    All this has nothing to do with OOP, but with syntactic sugar that is applied.

    • biddy@feddit.nl
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      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.

      • Square Singer@feddit.de
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 year ago

        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.