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.