And today in Laravel-land, how to take fluent APIs to the utmost consequences.

Better...? Seriously? All your lines got longer and you know have closures to run.

Um. Pass?

Did they have any explanation? Seems like utter bullcrap

Yeah, although it's awesome to have these methods available on the eloquent models, this looks like overkill.

i've used this just because Laravel people said its right way, they say the only advantage is passing the parameters... which was not the problem in the first place...

what makes me furious about laravel is how they assumed all php devs uses this format of braces

public function foo()

{

//bar

}

i'm so furious!.

As a laravel dev, I can disagree that it makes it less readable. It is a specific tool that you might apply only as needed, for example when filtering a lot of data. I've built the shop metadata filters with these and it worked perfectly, especially when I had to allow one to be selected if the other is preset.

Of course, as with everything in Laravel - it's up to you to decide if you need it. Suggestions are good as they might show something that you've missed :)

@potata would you clarify how bulkier code makes for more readability?

I mean, you're plainly replacing standard control structures (if/else) by convoluted closures. This is much worse if you ever need an extra variable inside the query you're making - i.e. you must set your closure to "use" extra things. ugh.

It MAY make sense when arrow functions arrive on PHP, but we're a bit far from that, yet. And this is not even a new concept on Laravel, to say they're "anticipating" something.

@elitedawn sorry, but not sorry. This ain't Laravel fault, this was decided by a body of decision-making PHP "elite", including a bunch of standard frameworks (www.php-fig.org). If you're new to PHP or have been living in a cave for the past years, it's called PSR-2, check an example of its styling rules here: http:///www.php-fig.org/psr/...

@igorsantos07 You see, it really depends. For me, a bulky code is symfony doctrine ORM but for them - our Laravel Eloquent is bulky as hell.

So, keep that perspective in mind.

Now, how does the logic extend? Well, if you are writing everything on a single file and single method - yes, if's are great, and might not be too bulky but I personally love to add each condition as a Scope in the model itself, so my query looks like this:
Model::includeDiscounts(request('discounts')->hasImage(request('has_image')->....->get()

Which in the model translates to a simple scoped $q->when($condition, function() {} );

And that is how I create readable code.

On the other hand, having whens - alow you to follow a DATABASE logic, rather than being separated by if's/elses, so that's personal preference what you want :)

@potata hmmmmmm got it. So what I posted was pretty much a dirty example, with a bad use-case, I guess.

Nonetheless, when() is going to be quite better with arrow functions from PHP 7.4!