> On Mar 25, 2021, at 5:28 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> 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".
Yes I can see you want a way to declare a local in an auto-capturing fn(), but
respectfully I do not see why using the function() syntax is not a viable
alternate solution when and if you want to explicitly not capture a variable.
I said "want" because you will never *need* to as you can always use a variable
name that is not in the outer scope.
And yes I know, someone may come along later and add a named variable in the
outer scope that matches your implicit local variable's name and potentially
break your code, but again if that is a concern why can't you just use
function() instead of fn()? And wouldn't they actually be breaking their code
(the outer code) if they did this?
Respectfully, you seem to be calling out a problem for which there is a
tailor-designed solution explicitly recommended in the RFC. How can function()
not address your stated concern?
> 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.
Depends on what your priorities are. If you priorities are coding in the
absolute most efficient manner and/or with the most clarity, no it is probably
not a bad thing.
But if your priorities are coding in the most robust manner where your code is
free from side-effects by design — in a functional style — and the performance
difference is insignificant, then yes it is a bad thing.
And at least one of the pair of RFCs spell out this motivation to allow for
more functional style explicitly.
>> 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*.
Respectfully again, to argue a use-case could be addressed in a different way
than proposed by the RFC when that different way uses a hypothetical language
feature that AFAIK does not have an RFC currently under consideration rings
hollow to me.
Minimally I would expect you to at least first float the hypothetical on the
list to see if there is appetite for it rather than just using is idea to snipe
at an RFC that many people appear to support.
> You mentioned:
>
> > prime examples are database transactions and using throw-aware buffering
> > handlers.
Actually, I did not provide that example. Other people did.
What I stated was I had other use-cases that concerned me more than
transactions, which I already explained in my email.
However, in no way do I mean to argue against their value for other developers
who mentioned them.
> 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.
But thanks for clarifying with examples, because I did ask for that.
That said, "with" is still hypothetical. Are you planning to champion its
inclusion into PHP with a discussion and then follow up RFC?
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
