RFC: Shall we remove the Craftzing\Laravel\Contracts\Ability interface

[remipelhate]

While I get why the Craftzing\Laravel\Contracts\Ability interface was added (and I would probably have done so myself), I feel like forcing it within the loosely-typed nature of the Gate API kinda worsten the DX.

Because the Gate API is loosely-typed, Craftzing\Laravel\Contracts\Ability::granted() has to use a mixed type for the $user argument in its method signature. And lead devs to either rely on docblocks or manual type checks in their code to ensure the actual type:

final readonly class VoteOnPollAbility implements Ability
{
    /** @param \App\Models\User $user */
    public function granted(mixed $user): bool
    {
        // or...
        assert($user instanceof User);
    }
}

I believe the DX may be better if we were to implement it without an interface as I proposed on the original PR to Laravel: laravel/framework#53729. Allowing devs to rely on proper argument type checks for me outweights the contract that is provided by the interface.

[ppelgrims]

My first thoughts were something along the lines of this:

The thing I do like about the interfaces is that it's easily composable, e.g. you don't need to check if you can call __invoke or granted etc. you know what to call. I reckon this can be overcome with a wrapper or so that handles this, but this doesn't sound like improved dx either.

but this already happens in user->can(), right now I'm leaning more towards:

A user defined contract (that extends the interface) which limits the ability to a subset of mixed, e.g. the User from the application? Maybe provided by the package with Illuminate\Foundation\Auth\User for the subset?

I'm not sure what to vote at the moment. What else could the alternative be to not having the granted method via contract? The exception? A call to method_exists first?

[remipelhate]

@ppelgrims Even with Illuminate\Foundation\Auth\User for the subset, the argument type would still be mixed as Laravel does not enforce any type. I would actually discard the interface entirely. AuthoriseUsingAbilities would then only apply if the passed ability is an object with a granted method (so yep, is_object and method_exists calls would be used). As maintainers, it's less appealing indeed, but as a consumer, you can then simply do:

namespace App\Abilities;

final readonly class VoteOnPollAbility
{
    public function granted(User $user): bool
    {
        return true;
    }
}

This way, you're also allowing consumers to define their own interface for abilities. For example, if we're using it on a project and only authorise user instances, we could setup the following interface:

namespace App\Abilities;

use App\Models\User;

interface Ability
{
    public function granted(User $user): bool;
}