[throwaway894345]

You'll have to define "OOP" first. Everyone thinks its defined, but even among OOP proponents there isn't consensus ("it's about message passing", "it's about encapsulation", "it's about inheritance", "it's about dot-method syntax", etc).

[g9yuayon]

My point is that the author needs to make it clear what exactly DOP can do better for. OOP, whatever how that is defined, is just an example of what people discussed under the OP.

[deltaonefour]

One way to define it is to look at the thing that's unique to OOP that isn't used in any other paradigm.

In OOP data and method are unionized into primitives that form the basic building blocks of your program.

This is unique to OOP. It must be the definition. Defining it in terms of message passing, encapsulation and inheritance are not as good because these concepts are used in other paradigms as well.

[danielscrubs]

Wouldn’t closures and let’s say “type-driven” also support your definition? It’s quite tricky as sometuple.fun() and fun(sometuple) might as well be interchangeable. If you really want to support a formal definition it would probably be best to have it in denotational semantics… not an easy task.

[jcelerier]

Closures aren't reusable across a whole program unlike classes since their type isn't named, and they don't allow to have more than one operation on the data held by the closure. They really are "poor man's objects" ;p

[uryga]

they allow as many operations as you need, just pass in a "method name" :)

  const p = Point(3, 5)
  p('getX') // 3
  p('up', 11)('toString') // "Point(3, 16)"


  const Point = (x, y) => (method, ...args) => {
    switch (method) {
      case 'getX': return x;
      case 'getY': return y;
      case 'toString': return `Point(${x}, ${y})`
      case 'up': return Point(x, y+args[0]);
      // ...
    }
  }

(unfortunately statically typing this statically requires... some work, either sth like [typescript overloads + literal types] or full on dependent types)

[deltaonefour]

Most things in programming aren't formally defined. It is especially hard given the isomorphisms everywhere.

At best what I've done here is eliminate some of the vagueness surrounding the definition, which is really all that's needed in most cases.