4 ms·

> "closures are just a poor man's object." Yes; the inverse is also true :) The "koan" is on c2 here: http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent http:

> "closures are just a poor man's object." Yes; the inverse is also true :) The "koan" is on c2 here: http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent (with a link to its original source).

gavinhoward 4y ago
Yes, that's the one!
mananaysiempre 4y ago
(Musings not that relevant to asynchronous ocap messaging, where the problems don’t really depend on whether you’re passing around objects or closures.) One thing I don’t think I’ve seen mentioned on those pages is the distinction between a “closed” object you can only send messages to and an “open” one you can inherit from / delegate to / mix in / COM-aggregate: the former is indeed a closure, that is some code and an environment, that you feed the message selector and some arguments; the latter is also some code and an environment, but you feed it the resend target, the message selector, and some arguments. So depending on what exactly you’re calling an object, an object is a closure... in one of two non-equivalent ways. Maybe not really a closure then? See also for not-quite-identical points of view: Piumarta’s note on prototypes in his COLA system[1]; Chisnall’s description of the (IIUC now-dead) new Objective-C runtime for Étoilé[2]. [1] https://www.piumarta.com/pepsi/prototypes.html https://www.piumarta.com/pepsi/prototypes.html [2] https://www.jot.fm/issues/issue_2009_01/article4.pdf https://www.jot.fm/issues/issue_2009_01/article4.pdf
- jerf 4y ago
  That's actually the point of the koan, in many ways. It is not true that an object is a closure and a closure is an object, in the sense that they are exactly the same in every way. Clearly they aren't, or we couldn't even have separate terms for them. The point is more that there is not a set of "closure problems" and a set of "object problems" that can only be solved with the relevant technologies. You can always put together a solution to a problem with the other technology. It may have different cost/benefit tradeoffs. It may have different affordances. I would certainly advise against walking into an object system and trying to force it to solve every problem by objects functioning as closures, and I would advise against walking into a closure system and trying to force it to solve every problem by forcing closures to work like objects. One should work with the grain of the wood you are working in rather than insisting on treating the wood like the pottery you are more familiar with. But it is always helpful to remember that within every object system is a closure system if you really need it, and within every closure system is an object system if you really need it. The resolution to "how can each be a subset of the other without them being equal to each other" is that there is some equivocation here. The object system that closures can implement conveniently is less rich than a dedicated object system, and vice versa. But if you just need to momentarily borrow the alternate concept, you probably don't need all the frippery you need if it is your primary tool for interacting with the world, so it works out.

gavinhoward 4y ago

Yes, that's the one!

mananaysiempre 4y ago

(Musings not that relevant to asynchronous ocap messaging, where the problems don’t really depend on whether you’re passing around objects or closures.) One thing I don’t think I’ve seen mentioned on those pages is the distinction between a “closed” object you can only send messages to and an “open” one you can inherit from / delegate to / mix in / COM-aggregate: the former is indeed a closure, that is some code and an environment, that you feed the message selector and some arguments; the latter is also some code and an environment, but you feed it the resend target, the message selector, and some arguments. So depending on what exactly you’re calling an object, an object is a closure... in one of two non-equivalent ways. Maybe not really a closure then? See also for not-quite-identical points of view: Piumarta’s note on prototypes in his COLA system[1]; Chisnall’s description of the (IIUC now-dead) new Objective-C runtime for Étoilé[2]. [1] https://www.piumarta.com/pepsi/prototypes.html https://www.piumarta.com/pepsi/prototypes.html [2] https://www.jot.fm/issues/issue_2009_01/article4.pdf https://www.jot.fm/issues/issue_2009_01/article4.pdf

jerf 4y ago
That's actually the point of the koan, in many ways. It is not true that an object is a closure and a closure is an object, in the sense that they are exactly the same in every way. Clearly they aren't, or we couldn't even have separate terms for them. The point is more that there is not a set of "closure problems" and a set of "object problems" that can only be solved with the relevant technologies. You can always put together a solution to a problem with the other technology. It may have different cost/benefit tradeoffs. It may have different affordances. I would certainly advise against walking into an object system and trying to force it to solve every problem by objects functioning as closures, and I would advise against walking into a closure system and trying to force it to solve every problem by forcing closures to work like objects. One should work with the grain of the wood you are working in rather than insisting on treating the wood like the pottery you are more familiar with. But it is always helpful to remember that within every object system is a closure system if you really need it, and within every closure system is an object system if you really need it. The resolution to "how can each be a subset of the other without them being equal to each other" is that there is some equivocation here. The object system that closures can implement conveniently is less rich than a dedicated object system, and vice versa. But if you just need to momentarily borrow the alternate concept, you probably don't need all the frippery you need if it is your primary tool for interacting with the world, so it works out.