Framework: [5.2] lists -> pluck rename

[SachinAgarwal1337]

pluck has already implemented as fetch in 5.1. Why rename lists to pluck?
lists is been used a lot in most of our codes. Its better to not rename it, or at least keep it as an alias, that will be helpful.

[GrahamCampbell]

We have kept aliases in 5.2.

[GrahamCampbell]

They're removed in 5.3.

[crynobone]

It should be kept a lot longer.

pluck() was an alias to values() (until it was deprecated in 5.1) in some cases and it suddenly become the new lists() in 5.2. I would personally feel it going to take a while for people to convert with the new idea.

[SachinAgarwal1337]

it will be great if lists is not removed at all even in 5.3 because the name lists make more sense then pluck with its functionality.

[mnpenner]

Why the heck did fetch disappear between 5.1 and 5.2? What happened to semver?

Methods should _never_ disappear between minor versions. You should slap an @deprecated on there with a message pointing users to the new function and then not remove it until the next major release. So much random stuff broken because of these pointless changes...

[GrahamCampbell]

What happened to semver?

We don't follow semver, and never claim to have done either. Minor releases WILL be breaking.

[GrahamCampbell]

We're like semver, only offset by a point, so semver major === laravel minor and semver minor === laravel patch.

[mnpenner]

Why wouldn't you follow semver? The cost of leaving a method in there is pretty much zilch. Just have the old method call the new one.

[GrahamCampbell]

It's a bit more than that, and that's not really up for discussion, nor is it my decision.

[GrahamCampbell]

Laravel has used this versioning strategy for years, and will continue to use it for years to come.

[mnpenner]

Well, you guys are making the upgrade paths needlessly painful, which is bad business for Forge.

[mnpenner]

It's actually worse than that. lists was deprecated and then pointed to the new method pluck but the return type was changed. It used to return an array, now it returns a Collection. Could have thrown a ->toArray() on there to maintain compat. Or even if you threw a Exception if you _really_ didn't want to maintain it, that would have been better. Now everything is breaking in subtle ways.

Actually, it's not even consistent. \Illuminate\Database\Query\Builder::pluck returns an array but \Illuminate\Database\Eloquent\Collection::pluck returns a \Illuminate\Support\Collection.

[GrahamCampbell]

Actually, it's not even consistent. \Illuminate\Database\Query\Builder::pluck returns an array but \Illuminate\Database\Eloquent\Collection::pluck returns a \Illuminate\Support\Collection.

We know.

[GrahamCampbell]

https://github.com/laravel/framework/pull/10552

[GrahamCampbell]

Well, you guys are making the upgrade paths needlessly painful, which is bad business for Forge.

No we're not? Semver would make ZERO difference other than just renaming our releases.

[mnpenner]

No we're not? Semver would make ZERO difference other than just renaming our releases.

I was talking about all the backwards incompatible changes, whether or not you follow semver.

However, semver would make it more clear to people who do use semver, and it would hopefully discourage breaking changes. So yes, it does make a difference. Node switched over to semver in ver 4, so it's not unprecedented, but I don't suspect Laravel will switch over any time soon, so I might as well stop talking.

[GrahamCampbell]

and it would hopefully discourage breaking changes.

Not at all. People just release a new major version. No biggie. I do this on all other repos I maintain.

[kneipp]

Why pluck() in 5.3 lost array params like lists() in previous versions?
Only can pass one string as reference.