[5.3] Closure vs callable about ideas HOT 9 CLOSED

As noted in that ticket in laravel framework, there are BC issues when it comes to overwriting these classes, as method signatures have to match exactly.

Taylor mentioned in that ticket that he's fine with doing it "where BC isn't affected" - that probably means only for classes that aren't likely to be overwritten.

from ideas.

Arrays and strings can also be callables. This is the fun part and affects all places where a parameter can be either a Closure or an array/string.

So, Container::bind has the signature function bind($abstract, $concrete = null, $shared = false) and is documented as @param \Closure|string|null $concrete. This means that the array or string I've bound successfully earlier would now be parsed as a callable and executed.

Another place is Route::get($uri, $action) with @param \Closure|array|string $action. Is it an array-array, or a callable-array?

What about Builder::where($column, $operator = null, $value = null, $boolean = 'and') with @param string|array|\Closure $column, how would you know if the value passed in should be parsed as callable or not?

There are many places where callable make sense, but there's also a lot of places that checks if ($value instanceof Closure), and those places will be hard to change.

Even if we're only talking about type hints in method signatures, and not part of the docblocks, it involves a lot of breaking changes. Everyone that has implemented an interface or overridden a method that is changed in this issue is forced to update their code. A package that has a custom PasswordBroker implementation (as an example) will have problem implementing a method with one signature in the old code, and one signature in the new code.

There are lots of backward-compatibility breaks involved when changing method signatures.

from ideas.

How about doing the switch for 5.4? ping @GrahamCampbell

from ideas.

I think that this PR it's so good not only for BC compatibility:

• Closures and anonymous functions are a bit less performant with OpCached applications.
• Code will be more clear, less copy&pasted and even more traceable with callables.

thanks

from ideas.

The upcoming Laravel 5.5 being a huge step (PHP 7 required, LTS version), it would be great to make the switch to callable in this release.

from ideas.

I will try to look into this as soon as possible and come up with a PR as a proposal.

from ideas.

Hi, i followed each topic that is associated with the closure vs callable and it's what brought me here. I also vote for the callable, but I might have led by the wrong idea, so we need advice.

I made class for custom validator registration

<?php

namespace App\Validators;

abstract class CustomValidator
{
    /**
     * Validator message when error occure
     * @var string
     */
    protected $message = null;

    /**
     * Enter point for validator registration
     * @return CustomValidator
     */
    public static function register()
    {
        $called_class = get_called_class();
        $validator = new $called_class;

        $validator->boot();
    }

    /**
     * Register validator and replacer
     */
    abstract public function boot();
}

And here is example of implementation

<?php

namespace App\Validators;

use Illuminate\Support\Facades\Validator;

class CsvAllowCustomValidator extends CustomValidator
{
    /**
     * Validator message when error occure
     * @var string
     */
    protected $message = "Field :field_name doesn't contain allowed values.";

    public function boot()
    {
        /* This works fine
        Validator::extend('csvAllow', 'App\Validators\CsvAllowCustomValidator@extend', $this->message);
        Validator::replacer('csvAllow', 'App\Validators\CsvAllowCustomValidator@replacer');
        */

        // But this won't work besause is not Closure
        Validator::extend('csvAllow', [$this, 'extend'], $this->message);
        Validator::replacer('csvAllow', [$this, 'replacer']);
    }

    public function extend($attribute, $value, $parameters, $validator)
    {
        $csvArray = explode(',', $value);

        return !count(array_diff($csvArray,$parameters));
    }

    public function replacer($message, $attribute, $rule, $parameters)
    {
        return str_replace(':field_name', $attribute, $message);
    }
}

Is this good approach and reason for using callable?
thanks

from ideas.

There's a only a few days left until 5.5 is released. Is there enough time to write the PR and test it for backward compatibility? This is probably a larger change and could target 5.6, at earliest.

from ideas.

@sisve Closure is callable, I think that there will not issues... but agree with you that it's better to avoid this kind of "inoffensive" changes now. Maybe 5.5.1 ;)

from ideas.