On 25/03/2021 04:12, Mike Schinkel wrote:
Actually, there is a way to declare a local variable. Use the long function syntax instead as there is no proposal to deprecate it.
That's not quite what I meant. I meant that you can't say "capture by default, but this variable is definitely local".
I'm guessing maybe "$foo = null;" at the top of the function would stop it auto-capturing, but the semantics of what exactly gets captured aren't spelled out in the RFC. That really needs to be added IMO.
Instead of using array_filter() with a side-effect free closure, I use a for loop because it is easier to reason about visually.
Is that a bad thing? In many cases it's probably more efficient, and easier to read.
It is not clear to me from reading the PEP how a "with" statement obviates the benefit of variable auto-capture? Maybe because I don't "think" in Python, so from reading their examples I cannot see how this relates?
I didn't mean to say that the "with" statement would replace closures in general, but it would make them unnecessary *for some specific use cases*. You mentioned:
prime examples are database transactions and using throw-aware buffering handlers.
If your current code looks something like this:
wrap_in_buffer(function($transaction) use ($to, $library, $thread, $author, $title, $library_name, $top_post) {
doSomething($to, $library, $thread);
andThenSomethingElse($author, $title, $library_name, $top_post);
});
That's a perfect use case for a Context Manager:
with ( wrap_in_buffer() ) {
doSomething($to, $library, $thread);
andThenSomethingElse($author, $title, $library_name, $top_post);
}
There's no callback, so no need to capture anything, and the implementation of all the try-catch-finally logic would be baked into the language, so the implementation of wrap_in_buffer() would also be much simpler.
Regards,
--
Rowan Tommins
[IMSoP]