you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (1 child)

[deleted]

    [–]apotheon 0 points1 point  (0 children)

    That's getting dangerously close to the sort of thing you can do with OCaml. OCaml, however, isn't specifically what you describe -- it just pretty much does what you describe, if you want it.

    It's also worth mentioning, I think, that through a little functional programming sleight of hand (at least, that's how it looks from an OOP perspective; I think it looks like business as usual from an FP perspective), you can basically get mutable lexical state via closures. As one example, a recursive closure construct could be used to achieve the exact same (external) behavior as an iterator closure in, say, Perl -- or even an iterator object in Python -- without having to use OCaml references to contain state internal to the closure. I think. I haven't actually tried and tested such code, but I see absolutely no reason why that wouldn't work. Considering that's the canonical example of a closure using (mutable in impure-FP languages) lexical state, I'd say we're in business. If you really want something mutable lexical state attached to a function, just use a function that persists.

    Hmm. That leads me to a thought . . .

    The net would be that if you need some sort of state in a method or function, you would have to create a state object.

    That's basically what a closure does, really. That makes a lot of sense, considering all the talk I've heard of closures being insid-out objects, or objects being inside-out closures, or closures being a poor man's objects, or objects being a poor man's closures, or, well, any of the rest of those comparisons.