[Proposal] return an array of strings from getFacadeAccessor

[imanghafoori1]

Currently Facades will eventually call one method on one object.

Maybe we return an array for strings or objects:

or the abstract string can may represent a "tag" on the container so that all the tagged instances get called. ( I think we should return 'tag' from an other method, and not getFacadeAccessor)

It starts to compete with events feature which already do the same job, but this can differ from that in the way, that each call is made with the result of the previous call.

the returned value of A1 is delivered as parameter to A2
and returned value from A2 to delivered to A3
The final value we get from the Facade call is the return value from A3

This is useful to add preConditions and postConditions to a method call or some how decorate it.
usage example:

• Converting null values to Null objects (postCondition)
• Normalizing parameters before handing them to the actual Facade (preCondition)

Note that the two cases above do not violate the L in SOLID
so if we apply them to existing Facades used in an app nothing breaks.

[fletch3555]

Can you give a concrete example of how this would work? I don't quite understand what you're even suggesting.

[sisve]

How would this work with type hints for those that are using them?

[imanghafoori1]

How would this work with type hints for those that are using them?

Sorry, but I do not get it exactly.

[imanghafoori1]

Here we extend the Calc@add to accept wider range of user input without modify it's code.
(With respect to Liskov's substitution principle.)

I tested my implementation with this and it worked for me :

// Re-usable parameter nomalizer layer
class ParamNormalizer
{
    function __call($method, $params)
    {
        return is_array($params[0]) ? $params[0] : $params;
    }
}

class ToInt
{
    function __call($method, $a)
    {
        return array_map(function ($el) {
            return (int) $el;
        }, $a[0]);
    }
}

// This class is rock solid,
// We do not want to tamper with it.
// but we need some behavior around it any way.
// it only accepts an array of integers. [1, 2, 3]
class Calc
{
    function add(array $a)
    {
        return array_sum($a);
    }
}

class MyFacade extends \Illuminate\Support\Facades\Facade
{
    protected static function getFacadeAccessor()
    {
        return [ParamNormalizer::class, ToInt::class, Calc::class];
    }
}

// Now we can use it the way we want...
// we can now send it numeric strings, and variable number of arguments.
MyFacade::add(1, 2, 3); // 6

MyFacade::add([1, 2, 3]); // 6

MyFacade::add('1', '2', 3); // 6

MyFacade::add(['1', '2', 3]); // 6

So instead of writing code throughout the entire application to cast string numbers to int and etc,
we just included some reusable parameter modifiers in the Facade definition class

[imanghafoori1]

maybe we can put an array of preConditions and postConditions in separate methods.

class MyFacade extends \Illuminate\Support\Facades\Facade
{
    protected static function getPreFacadeHandlers()
    {
        return [ParamNormalizer::class, ToInt::class,];
    }

    protected static function getFacadeAccessor()
    {
        return Calc::class;
    }

    protected static function getPostFacadeHandlers()
    {
        return [...];
    } 
}

I think is more sensible

[mfn]

What is the point of all of this, where is to goal to get, what problem is it solving?

How would everyone using the Laravel Framework benefit from this and pre/post conditions?

It adds so much more magic for what exactly?

These ideas don't even sound useful on paper, just confusing (to me). 🤷‍♀️

[imanghafoori1]

Let me shed some light on it.
We just want to add some code to an existing structure or class without changing it.
In this over simplified example the Calc::class comes from a library or composer package.

We want to add some behavior to it without changing the actual class code.
I my self have needed such a thing in many cases of my day to day work.

It just gives end-users opportunity to have cleaner code bases and more code reuse.
Laravel itself has repeated this peace of code through out many places
is_array($params[0]) ? $params[0] : $params;

The other use case is to add postConditions to implement the null object pattern with out tampering with the original classes.

Or Imagine a repository class from a package, you want to fire events before and after the calling methods on the repository, but the package does not do that for you.

UserCreated event, UserCreating event, ...

Then you can do that using a post and pre.

I think (but not every one) preConditions are nifty places to add some authorization or validation.

The terms preConditions and postConditions are coming on my tongue from Design By Contract concepts by Bertrand Meyer.

You may spend some time on these pages :

https://en.wikipedia.org/wiki/Design_by_contract

https://github.com/php-deal/framework/wiki

Thanks for attention.

[martinbean]

A façade class exists solely to pull something from the service container. That’s why the façade accessor returns a single string: it’s saying what it wants from the container. It has nothing to do with asserting conditions, casting parameters etc.

A façade class is literally for saying, “Get me [foo] from the container” without having to pass the container around your application.

[imanghafoori1]

A façade class exists solely to pull something from the service container.

No it's not just that, obviously.
If you look at it's source code. you can see that you can return an object from the getFacadeAccessor.
then it has noting to do with the container's resolving and will use that object.

Facade builds many other features around pull something from the service container.
Like aiding tests, making the resolved instance singleton, etc
I do not want to mention them all. you can take a look at the base facade class.

[martinbean]

you can take a look at the base facade class.

@imanghafoori1 I’m familiar with the Facade class. I’m also aware that getFacadeAccessor should return a string, not an object: https://github.com/laravel/framework/blob/27469f0a700569aa7ee3256c56ad553c96ce34b2/src/Illuminate/Support/Facades/Facade.php#L150

Yes, Laravel façades comes with aids for things like testing and mocking, but it’s primary purpose is to proxy calls to something bound in the container. That’s why it’s called a façade!

[imanghafoori1]

Let me mention that when I say you I mean everyone who reads the discussion thread. otherwise I mention the the specific person, explicitly.

Keep in mind that many people think that Facades in laravel are not really an implementation of the Facade design pattern, in fact they are proxies.

https://www.youtube.com/watch?v=JV7fiM8r3nc 4:20

[martinbean]

@imanghafoori1 If you return an object from the façade, then exactly what is it a façade for…? It instead just becomes an object that magically builds another object.

[martinbean]

If you return an object it is not longer memoized and each time you you call your facade you get a new instance.

@imanghafoori1 Not true. It depends how the object has been bound in the container. If it’s been bound as a singleton then calling the façade multiple times will only ever instantiate one instance and return it each time:

That was calling FooFacade::getFacadeRoot() twice. Notice how both objects have the same ID (#216)?

So yeah, I’m struggling to see concisely what it is you’re proposing and what problem it solves.

[imanghafoori1]

It seems that you have used app()->make() in the getFacadeAccessor and not the new keyword yeah ?
use it like this :

protected static function getFacadeAccessor()
{
   return new Calc();
}

[martinbean]

It seems that you have used app()->make() in the getFacadeAccessor and not the new keyword yeah ?

@imanghafoori1 No, I used a façade how it was meant.

I created a service provider and put something in the container:

class FooServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->app->singleton('foo', function () {
            return new Foo;
        });
    }
}

I then created a façade that references this item in the container:

class Foo extends Facade
{
    protected static function getFacadeAccessor()
    {
        return 'foo'; // Key in container
    }
}

So now when I use the façade, it’ll resolve the foo key from the container, which is a singleton, so the same instance will be returned each time:

$instanceOne = FooFacade::getFacadeRoot();
$instanceTwo = FooFacade::getFacadeRoot();

dd($instanceOne, $instanceTwo);

// $instanceOne and $instanceTwo both point to same instance

I think you need to re-visit how façades work, before suggesting overhauling how they’re constructed and what they’re used for.