Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[13.x] Adapting blank to Evaluate Closures #55277

Conversation

devajmeireles
Copy link
Contributor

The blank is an extremely useful helper, but with one flaw: it does not support evaluating closures. With this PR, we have added support for evaluating closures primarily within the scope of the blank method so that the $value is evaluated right afterward.

Before:

blank(fn () => null); // false

After:

blank(fn () => null); // true

@henzeb
Copy link
Contributor

henzeb commented Apr 4, 2025

I don't think this is how it should be. What if a value can be blank or closure?

What is wrong with this solution?

blank(value(fn() => null)); // true

@devajmeireles
Copy link
Contributor Author

I don't think this is how it should be. What if a value can be blank or closure?

What is wrong with this solution?

blank(value(fn() => null)); // true

Hey, henzeb! Thanks for sharing your thoughts.

Although there is nothing wrong with your code example, in my opinion there is a certain effort to use two helpers to obtain such a simple result as just blank(fn () => null).

Furthermore, by adopting this PR we can be sure that blank is covering cases where we do not know the type of the variable - also because Blank accepts mixed, but in reality it is a closure. So blank will be able to evaluate it correctly 😉

@henzeb
Copy link
Contributor

henzeb commented Apr 4, 2025

I don't think this is how it should be. What if a value can be blank or closure?
What is wrong with this solution?

blank(value(fn() => null)); // true

Hey, henzeb! Thanks for sharing your thoughts.

Although there is nothing wrong with your code example, in my opinion there is a certain effort to use two helpers to obtain such a simple result as just blank(fn () => null).

Furthermore, by adopting this PR we can be sure that blank is covering cases where we do not know the type of the variable - also because Blank accepts mixed, but in reality it is a closure. So blank will be able to evaluate it correctly 😉

yeah, but with the two helper solution you have control over that.

imagining the following:

$canBeAnything = fn()=>'I do not want to evaluate this function executing things here right away, but I want to pass it along to a job queue';
if(!blank($canBeAnything)) {
    MyJob::dispatch($aClosure);
}

when blank handles closures, you'd be stuck with a simple null check even if you want to dispatch only when not empty, no matter what the value is, as long as it is not blank.

This is going to break a lot of code, and it isn't even worth it, IMHO.

@taylorotwell
Copy link
Member

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If applicable, please consider releasing your code as a package so that the community can still take advantage of your contributions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants