[Proposal] Standardise 'has' method behaviour throughout the framework

[ntzm]

The problem

There is some inconsistency in the framework regarding checking for things using has methods: there are some which allow for multiple checks in one call, and others than only allow for single checks, as detailed below.

Can check multiple

The following functions can take arguments as a single key, and array of keys, or multiple arguments. They return true if all keys exist.

• Illuminate\Http\Request::{has|exists}()
• Illuminate\Http\Request::has{Cookie|File|Header}()
• Illuminate\Support\Arr::has()
• Illuminate\Session\Store::{has|exists}()

These functions can take a single key or an array of keys, due to them using Arr::has(), but it is not advertised in the PHPDoc. They return true if all keys exist.

• Illuminate\Config\Repository::has()
• Illuminate\Validation\Validator::hasAttribute()

The same as above, but they return true if at least one of the keys exist.

• Illuminate\Validation\Validator::hasRule()

  Can only check single

And these can only check single keys.

• Illuminate\Routing\Route::hasParameter()
• Illuminate\Routing\Router::has()
• Illuminate\Routing\RouteCollection::hasNamedRoute()
• Illuminate\Console\Command::has{Option|Argument}()
• Illuminate\Auth\Access\Gate::has()
• Illuminate\Translation\Translator::{has|hasForLocale}()
• Illuminate\View\Factory::{hasSection|exists}()
• Illuminate\Database\ConnectionResolver::hasConnection()
• Illuminate\Database\Schema\Builder::hasTable()
• Illuminate\Database\Schema\{MySql|Postgres}Builder::hasTable()
• Illuminate\Cookie\CookieJar::hasQueued()
• Illuminate\Support\ViewErrorBag::hasBag()
• Illuminate\Session\Store::hasOldInput()
• Illuminate\Foundation\Http\Kernel::hasMiddleware()
• Illuminate\Cache\Repository::has()
• Illuminate\Support\Facades\Cookie::has()
• Illuminate\Support\Collection::has()
• Illuminate\Filesystem\Filesystem::exists()
• Illuminate\Filesystem\FilesystemAdapter::exists()
• Illuminate\Auth\Passwords\DatabaseTokenRepository::exists()
• Illuminate\Support\Arr::exists()

  Special mentions

• Illuminate\Database\Schema has a hasColumn, which checks a single column and hasColumns, which can take an array of columns to check, and will return true if they all exist.
• Illuminate\Support\MessageBag has a has, which can check an array of keys and will return true if they all exist, and hasAny, which will return true if at least one of the keys exists.

This may not be an extensive list, but I believe I got most of them. Some of these also may be in the wrong category, as I only did a quick scan of each function to figure out what it did.

Proposal

Here is my proposal:

• A hasAny method is added to every class with a has method, which will return true if at least one of the given key exists.
• A hasAll method is added to every class with a has method, which will return true if all of the given keys exist.
• The current has methods are changed to mimic the behaviour of hasAll, in a way that does not cause breaking changes.
• The current exists methods are changed to accept multiple inputs in array or multiple argument form, and will return true if all given things exist.
• Classes with methods such as hasTable are given a method where you can check multiple, such as hasTables.
• These multiple methods, when not supplied with any keys, return true if any exist. (e.g. hasTables() would return true if there were any tables at all.

Obviously these are just ideas, feel free to add and critique, I haven't really thought a whole lot about it.

[tristanbailey]

Would you not also think of adding standard naming where existing methods exist and passing though the old ones so they could be depreciated.

To understand if it is the standard use or the standard naming as well you are interested in, as I think you have a good point.

[ntzm]

@tristanbailey Sorry I don't quite understand what you mean

[tristanbailey]

@ntzm Hi, you have made a comment to unify the has() statements but at the moment your fork has some changes of function but not renaming the for example hasQueued() to has() (I understand you are still working so could change)

To do this and keep backwards compatibility you could add pass throughs, allowing for migration.

has($key) {
    return self:: hasQueued($key);
}

So was asking is the No 1 aim to have all methods behaviour the same or to be named the same also, to point to this fact?

[tristanbailey]

side note: Some methods like Illuminate\Foundation\Http\Kernel::hasMiddleware() might not be appropriate to call Kernel::has() on, so maybe as an addition to your proposal an optional param of 'type' might be needed

// idea code 
public function has($key, $type='Middleware') {
    // ... if type middleware 
    // ... if type auth
    // ...
}

[ntzm]

@tristanbailey I didn't mean we should rename the methods, just allow them to be passed multiple arguments. Sorry for the confusion

[troccoli]

@ntzm, I don't know how far you've got with it and I would like to help if I can.

I found this proposal because I was tired of writing something like if (!$collection->has('key')), and I wanted to contribute to make Laravel better.

So, I would propose two more methods:

• doesNotHave, which would accept a single key
• doesNotHaveAny, which would accept a single key, an array of keys or a list of keys, basically as the current(5.7) Illuminate\Support\Collection::has() method.