Comment by llmslave2 | Hacker News Reader

Comment by llmslave2 | Hacker News Reader

Parent Full thread

Anything where you have literal "instances" of something with common state/behaviour is prime for inheritance, but that's different from trying to model a domain as a set of hierarchal objects.

But I do like classes - you can use them without inheritance, and the other stuff that comes with them (encapsulation, polymorphism, etc) fits my mental model. [0] Classes are just syntactic sugar over closures at the end of the day.

But inheritance is best when it's limited and shallow.

0:

  The venerable master Qc Na was walking with his student, Anton. Hoping
  to prompt the master into a discussion, Anton said "Master, I have
  heard that objects are a very good thing - is this true?" Qc Na looked
  pityingly at his student and replied, "Foolish pupil - objects are
  merely a poor man's closures."

  Chastised, Anton took his leave from his master and returned to his
  cell, intent on studying closures. He carefully read the entire
  "Lambda: The Ultimate..." series of papers and its cousins, and
  implemented a small Scheme interpreter with a closure-based object
  system. He learned much, and looked forward to informing his master of
  his progress.

  On his next walk with Qc Na, Anton attempted to impress his master by
  saying "Master, I have diligently studied the matter, and now
  understand that objects are truly a poor man's closures." Qc Na
  responded by hitting Anton with his stick, saying "When will you
  learn? Closures are a poor man's object." At that moment, Anton became
  enlightened.

I guess closures in languages like Scheme can have multiple "methods"? In C++ and Rust, closures (lambdas) are one function with attached state variables. I guess there are ways to attach more callables to a bag of state, but they would involve one lambda for each callable and shared state captured by reference (and good luck dealing with lifecycle issues).

> I guess closures in languages like Scheme can have multiple "methods"?

At the language implementation level, Scheme-like closures only have one operation, which is the ability to apply them to arguments and thus evaluate them. But as a couple of the other replies show, a closure's code can be implemented as a dispatcher which handles multiple methods. That's not a language feature, just user code.

I wrote the koan quoted above in 2003, a few years before Graydon Hoare started working on Rust. At the time, there weren't any "static" languages with built-in support for closures.

Even Python had only had read-only closure support for a couple of years at that point - so those closures couldn't be used to implement mutation of closed-over variables. (Python didn't get mutable closures until around 2008.) Java only got closure support in version 8 around 2014. C++ 11 got closures in 2011.

Of course you can implement dynamic-dispatching objects using closures in Rust or C++, but that's not going to be the equivalent of a statically-defined structure.

a tuple of closures closing over the same object ('let over lambda') is equivalent to an interface.

You can do it multiple ways. Like in go:

   cloj := func() {
     val := 1
     return func(m string) {
       switch m {
         case "inc": val = val + 1
         case "dec": val = val - 1
       }
     }
   } ()
   
   cloj("inc")

In JS you can close upon state and return an object, which is essentially how classes work in the language.

   let cloj = (() => {
     let x = 0; return { inc: () => x++, dec: () => x-- }
   })()
   cloj.inc()

Reply on news.ycombinator.com