3 ms·
> Functions have no internal state. But closures do. And thus, why closures are a poor man's objects, and objects are a poor man's closures. As an example, Jav
by jdmichal 10y ago
> Functions have no internal state.
But closures do. And thus, why closures are a poor man's objects, and objects are a poor man's closures. As an example, Java closures are really anonymous objects with the closed state as instance variables.
> More importantly you could have multiple instances of that shard state without explicit management, saving a lot of complexity and effort.
Technically that's what classes gives you, not objects. But agreed on the sentiment.
- jstimpfle 10y agoIf you apply this common understanding of "closure" where the values that closures close over are not really values but mutable objects, then closures don't count as (pure) functions. If one thinks of them as proxies to the closed-over objects, they are quite like "procedures". Another way to think about them is simply as objects with only a single method.
- jdmichal 10y agoThey are definitely still "functions", barring the fact that Java doesn't have first-class functions and SAMs are the closest thing. C# does have first-class functions, and it is even more liberal in its closure rules. (Java can only close over `final` variables, which are immutable variable bindings. C# doesn't even have immutable variable bindings, only member bindings.) Also, they can still be "pure functions". Purity is a relation of side effects, not of mechanisms. (Even then, it's a somewhat loose definition -- is allocating memory a side effect?) If you don't allow closures to escape their declared scope, you can handle closed values as extra parameters. So closures don't mean you suddenly can't write pure functions, it means that some input to the function is pre-determined. In other words, closures have the same implications to purity as parameter binding -- absolutely none.
- jstimpfle 10y agoYou are kind-of making my point. It's clearer to use "function" fore pure, mathematical functions, and otherwise "procedure"/"object"/"proxy"/"closure" whatever. Even if some popular languages misuse the term "function". > Even then, it's a somewhat loose definition -- is allocating memory a side effect? This is leading nowhere. Is loading a value into a register a side effect? If you care.
- jdmichal 10y agoI mean, if you're only point is that programmers use the term "function" to mean something other than a pure mathematical mapping from one set to another... You won't get any arguments from me.
- gnaritas 10y ago> Technically that's what classes gives you, not objects. But agreed on the sentiment. No, that's what objects give you. Classes are merely one means of creating objects (others exist), but the benefits come from the objects, not their means of construction.
- jdmichal 10y agoMy point is that you can have an OOP language / system that consists entirely of singletons. The ability to create multiple object instances from a template is classes or prototypes or whatever other mechanism. It's not something strictly necessary to OOP.
- gnaritas 10y agoYea, I have no idea what you're trying to convey. Additionally, a system built entirely with singletons isn't object oriented, it's procedural with modules.