Re^3: Real life uses for closures.

[Dallaylaen]

in reply to Re^2: Real life uses for closures.
in thread Real life uses for closures.

To be honest, at the time of my writing my "definition" of closures was "functions holding refs to outer variables". I went to re-read the wikipedia article shortly after posting.

That said, I have yet to come across a case where several functions share the same context (aside from global variables, e.g. my $foo in the beginning of a package). If I was to design something like that (especially if the context was supposed to be mutable), I would probably end up with a class. Perl is object-oriented, after all.

An example I could imagine was several AnyEvent callback sharing the same resource guard - where resource is not released until all callbacks have either fired, or failed. But this is, again, closer to "generation of subs" then to "use of full power of closures".

[davido]

I mentioned this earlier, but might have been a little vague: Bytes::Random::Secure is a module that has both an OO and a "functions" interface. The functions interface is for simplicity, and the OO interface is for configurability. The functions interface is just a thin wrapper over a single private instantiation of the OO interface. That module only instantiates an internal-use object if one of the "functions" is used, so lazy instantiation. The functions all share the same object, once one is created. And the object must not be accessible outside of the scope of the module, so that it cannot be tampered with (easily).

So we use a narrowly scoped lexical to hold the object, and the functions that have access to it hold closures to the object.

A lot of strategies were tossed about before settling on this implementation. All (including this approach) have one drawback or another. This seemed to be the least nutty. As for the decision to have a module that provides two interfaces, that was because we ran out of gas on being able to provide per-caller configurability and compartmentalization without going to an object interface, and yet didn't want to break our easy to use "functions" interface.

So this is an example of using a closure to share an object across several functions. In a way it feels a little like C programming, where "OO" means passing a handle around. Only because we get to use a closure there's no need to bother the user with some handle.