Paginators and Other Collection Decorators Should Implement Enumerable or a Sub-Interface of Enumerable

[kaan-atakan]

Sometimes I want to type hint a method's parameter to know whether it is a Collection or a decorator for a Collection like a LengthAwarePaginator. Most of the time it's because I want to use the pluck method, but there can be other circumstances. The way the code is currently structured I can either:

• Type hint iterable or Traversible, both of which are too broad and don't guarantee I can use collection methods, or:
• Type hint Enumerable or Collection, both of which are too narrow and exclude decorators for the collections

Looking at some of the decorators I notice that they use the __call magic method to call the underlying Collection's methods. These would need to be rolled out to regular intermediary methods. So for example:

public function pluck($value, $key=null) {
    return $this->getCollection()->pluck($value, $key);
}

There are also other alternatives that would solve my use cases:

• A Collectible Interface, to be implemented by Collection and it's decorators that defines a method getCollection or toCollection that returns the underlying collection for decorators and $this if it's a subclass of Collection. With this method I could type hint an iterable parameter and check to see if the parameter is Collectible and then depending on the result either calling the getCollection method or passing the parameter to the collect helper. I don't prefer this because I think it will lead to repetitive verbosity near business logic, even though it would be more or less trivial to implement and shouldn't break anyone else's code.

• Changing getArrayableItems method of the Collection base class, that is called from the constructor) to check for the Paginator contract (and any other decorator) and return the paginator's items array instead of calling the toArray method during the Arrayable check which returns an array of various Paginator properties rather than just the data. This way I could call collect on an iterable parameter knowing that I will always get a Collection instance with the correct data. This is would be a decent alternative but for the fact that it needlessly creates a copy of the collection. It might also break some people's code, though I doubt it.

• Changing decorators' toArray methods to return an array of the data instead of selected properties. Again, this way I could safely call collect on the parameter to ensure that I have a collection. This is more likely to break people's code, so I think it's the worst option.

I personally think that rolling out the Enumerable methods in the Collection decorators is the best way because

• We can avoid calling the collect helper which will needlessly create a copy of the collection (or underlying collection with the decorators) when called on a Collection or a decorator.
• Type hinting iterable and calling collect will also work with this method, making it functionally the same as the other three but more flexible.
• The decorators will be more self documenting as a result.
• It's also very unlikely to break anyone's code, though if we want to be absolutely sure we can extend a new interface from Enumerable with another name (Collectible maybe) and implement that in the relevant classes instead.

I would be glad to do the work myself and issue a pull request, but I don't want to bother if it isn't going to make it into the main branch. I would also like some guidance on how to proceed. Ideally i would like to see this in laravel 6.x (since that's what most of my projects use) but I will settle for 8.x

[kaan-atakan]

Will anyone respond to this? I might end up solving my use case by moving pagination out of the repository and into the controller, but it's a fairly major refactor (actually bigger than any of the modifications to the framework, that I have suggested)