3 ms·
Right, in a language where "everything is an Object" it only makes sense that closures should be Objects as well, and that you can interact with them by sending
by galaxyLogic 4y ago
Right, in a language where "everything is an Object" it only makes sense that closures should be Objects as well, and that you can interact with them by sending messages to them. Then add a little bit of syntactic sugar, to make the code more succinct.
Another innovation of Smalltalk which may not be familiar to everybody is that all control structures in Smalltalk are implemented by passing closure-objects as arguments to methods like ifTrue:ifFalse .
- igouy 4y ago> … all control structures in Smalltalk are implemented by… "… compiler optimises ifTrue:ifFalse: and friends using special opcodes, so as to avoid having to create closures…" https://stackoverflow.com/questions/32662354/optimising-iftrueiffalse-in-smalltalk https://stackoverflow.com/questions/32662354/optimising-iftr...
- galaxyLogic 4y agoGood point. But that's a technical implementation optimization, which the programmer does not need to be aware of. It's like saying that functional languages implement tail-recursion as iteration in order to "get rid of" recursion. But the programmer can still think in terms of recursive calls in their program, and can reason about the correctness of the program by assuming it works by recursion.
- igouy 4y ago> … which the programmer does not need to be aware of… Except when they do! When they expect to be able to change those methods, because they have been led to believe they are just methods.