Hacker News Reader

Comment by goto11 | Hacker News Reader

Objects are just a poor mans closure.

Closures are just a poor mans object.

(Not sure where this quote is from originally? Maybe here: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...)

View on HN

There also is the classical example of defining cons, car, and cdr as closures in SICP:

  (define (cons x y)
    (lambda (m) (m x y)))

  (define (car z)
    (z (lambda (p q) p)))

  (define (cdr z)
    (z (lambda (p q) q)))

Here, cons, instead of returning an object with two values, returns a closure that captures the two values. car and cdr call that closure, passing it another closure. The cons closure calls that closure, passing the the two values.

Explanation at https://stackoverflow.com/questions/21769348/use-of-lambda-f....

https://en.wikipedia.org/wiki/Church_encoding

Also, https://en.wikipedia.org/wiki/Scott_encoding

Of course, it completely kills (or "stress-tests", if you will) the branch predictor in your CPU.

I like this explanation - https://stevelosh.com/blog/2013/03/list-out-of-lambda/ .

It means that the "rich" man has objects and closures, for the situations where each one is the best fit.

See https://www.perlmonks.org/?node_id=75831 for a similar sentiment from me a couple of years before that.

My exact quote was, While closures may look like a poor man's object, I think the reverse is closer to the case.

That's literally true in Lua, where there is no such thing as object-orientation but there's lots of ways to do object-oriented programming. The simplest, most performant way I've found is to return a hash map containing lexical closures and data from a "constructor" function. Any enclosed functions which refer to values declared in the constructor use those values in a closure, so it's easy to do instance or static member fields by putting the field declaration inside or outside of the constructor function.

You can do it with metatable manipulation as well(changing the functions which map to specific table operators which lets you change how unmapped keys are handled) but I found the lexical closures to make a lot more sense.

> Maybe here: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m....

As far as I know, yes, that's the oldest I've been able to find.

It'd be nice to be able to blur the lines. Maybe implement multireturn by declaring variables public inside your closure scope.

  function Person(firstName, lastName) {
    let fName = firstName; 
    let lName = lastName;

    public getFullName = function() { 
      return fName + ' ' + lName;
    };
    
    public setFirstName = function(firstName) { 
      fName = firstName;
    };
    
    return this;
  }

("return this" is probably not the best syntax at the end there, especially if bolting this onto javascript.)

I remember trying to think about something similar when I wanted to invent a language that tries to stay as close to “everything is an X” as possible. (But it was a mess, unfortunately)

I would use “return scope”.

"scope" was actually on my short list of possibilities :-)

That's just Python classes.

Probably the early schemes for doing objects in LISP, from the Symbolics refrigerator-sized LISP machine era, which worked that way.

Closures in which sense here? Like closure operators?

This closure https://en.wikipedia.org/wiki/Closure_(computer_programming)

Link because this describes it more thoroughly and more precisely than I can.

Closure in the sense of a function which capture free variables in the outer scope. The captured variables are like fields in an object instance since they retain their state between invocations of the function. So a closure can be thought of like an object with a single method - hence a poor mans object :-)

Also not necessarily a function, both rust and js support closures in brackets.

A block introduces a lexical sub-scope but it's not a closure, because there's no closing over: the "closing over" part is about a function accessing its definition context during its execution. A block doesn't have such a distinction.

This correspondence is made abundantly clear by C++ which explicitly defines its lambda functions ”as if” they desugared into objects of appropriate anonymous compiler-generated struct/class types. Also Java, which has had closures since day one, but used to call them ”anonymous inner classes” and forced people to use a ridiculously verbose syntax to define them.

This is literally how Delphi implements closures/anonymous methods.

The compiler will generate a class with fields for whatever variables are captured, and then instantiate it for you, assign the fields etc.

If you define your function reference as a type (as it's called), you can even inherit[1] from it and add additional overloads to the inherited class, to make it do multiple things.

[1]: https://delphisorcery.blogspot.com/2015/06/anonymous-method-...

Reply on news.ycombinator.com