4 ms·
> I think an even more interesting perspective is that they aren't the same thing, but they can be implemented in terms of each other. I don’t know, I think th
by OskarS 5y ago
> I think an even more interesting perspective is that they aren't the same thing, but they can be implemented in terms of each other.
I don’t know, I think that it’s perfectly reasonable even from an engineering/computer science perspective to say that they are literally the same thing, just viewed from two different perspectives.
After all, what is an object? It’s some code, with bundled data. What is a closure? It’s some code… with some bundled data. I think it’s fair to say that this is a “is it a vase or two faces?” situation. You’re looking at the same image, just seeing it from different perspectives.
- sullyj3 5y agoOne key difference is that usually the captured values in a closure can't be mutated.
- pritambaral 5y agoI don't know where you're getting that from. In lambda calculus — where closures were first developed — there's no restrictions against mutation of captured variables or values.
- sullyj3 5y agoUh.. what? There isn't even a concept of mutation in lambda calculus.
- pritambaral 5y agoOnly in pure lambda calculus. But that's not because of closures. That's for all variables everywhere; captured, free, whatever. So your original statement — "usually the captured values in a closure can't be mutated" — still has no basis even if you insist "But, pure λ-calculus has no mutations". It's not because of closures that the captured variables became immutable. When used in any of many lambda calculi that do have mutations, closures support mutation just the same as any variable. Whether a variable is free or captured, that doesn't change if or how it can be mutated.