4 ms·
How do you manage to not have global objects? FP and imperative handle data without huge amounts of global state the same way. By structuring your code properl
by lostcolony 6y ago
How do you manage to not have global objects?
FP and imperative handle data without huge amounts of global state the same way. By structuring your code properly.
Per your example, your Client instance still has to be passed around everywhere it's needed, and you call client.push_data() on it; in FP or imperative approaches, you would pass around a Client struct or tuple or similar, and call push_data(client).
OO just bundles state and functions together, as fields and methods on an object. Which has its pros, and its cons.
- zabzonk 6y ago> Per your example, your Client instance still has to be passed around everywhere it's needed Yes, because our program probably needs more than one Client.
- lostcolony 6y agoNot sure if you're trying to make a point here?
- deleted 6y ago[deleted]
- na85 6y agoI mean in Java or C# there are "global" objects, being the Main class, I suppose. There's always a top-level construct. But my Sword class doesn't hold a reference to a NetState object.
- lostcolony 6y agoThat was a rhetorical statement. The same reason you don't need global objects in an OO language is the reason you don't need global data structures in an imperative or functional one. Your Sword class doesn't hold a reference to a NetState object, but then, my Sword struct doesn't need a reference to a NetState struct, either. If I were to climb the reference hierarchies back to my 'main' function, I would find a common ancestor, just like in OO if I were to climb my reference hierarchies, I would get back to the class with my 'main' method. But that doesn't imply global state; it's all scoped down in the code where I defined and use it.
- na85 6y agoI haven't the faintest clue what point you're trying to make but I'm sure it's very clever.
- bcrosby95 6y agoThe point is the graph of data dependencies in an FP system doesn't necessarily look any different than in an OO one.
- andi999 6y agoClosures and internal state of objects are basically the same thing.
- throwaway894345 6y agoI don't usually deal with stateful closures. In OO we often have file objects, and if you call Close() on said object, subsequent Read() invocations fail because the encapsulated state has changed. What's the closure analog for this?
- lostcolony 6y agoYou've never worked with a generator before? That's a stateful function. For throwing after a file handle is closed, something like - const read = (fileHandle) => { return () => { if io:isOpen(fileHandle) && io:hasNext(fileHandle) => { return io:readNext(fileHandle) } else if io:isOpen(fileHandle) {return undefined } else {throw "File is closed"} } }(myFile) read() read() io:close(myFile) read() //throws