Translations with Anonymous Function

Translations with Anonymous Function.php

<?php

namespace Molajo;
{

    /** Translation Class */
    class Language implements LanguageInterface
    {
        public function translate($key)
        {
            if ($key == 'h') {
                return 'Hello';
            } else {
                return 'Goodbye';
            }
        }
    }


    /** Concrete Class */
    class Test
    {
        protected $language;

        public function __construct($language)
        {
            $this->language = $language;
        }

        public function t($key)
        {
            $t = $this->language;
            return $t($key);
        }

        public function doThisThing()
        {
            $message = 'ABC ' . $this->t('h') . ' ZYZ.';

            return $message;
        }
    }


    /** Anonymous Function */
        $t = function ($request) {
            $class = 'Molajo\\Language';
            $language = new $class();
            $value = $language->translate($request);
            return $value;
        };

    /** Pass in the Translation Function */
    $class = 'Molajo\\Test';
    $test = new $class($t);

    $thing = $test->doThisThing();
    echo $thing;
}

There are certain features that are used broadly across an application and framework. Language, Events, Logging, Filesystem activities, are all examples of that type of broad role.

I've been thinking about how best to structure the architecture so that it's not closely coupled to specific implementations of those features.

In this example, I am playing around with the idea of passing an anonymous function in with a callback to the Language class. Given a common interface, I think this could be a useful way to handle that type of feature.

What do you think? Would this work? Is it a good idea? Any ideas of other/better approaches?

Can you explain more why you don't just pass the Language implementation to your concrete?

@taylorotwell - first, very much appreciate your review. You are the integration master.

What I am trying to do is make certain all of my base framework classes can be consumed as packages with minimal dependencies. I also want to make certain that my packages can be swapped out for that of others. (That's background, not an answer).

Application-wide services, such as language, logging, etc., are extra challenging because they can easily create dependencies in (likely) all packages. Unless as an industry, we share a common interface, if I create and inject an interface, then I have created a dependency on my package. (Unless others use the Interface, I need an adapter/handler for each option).

So, this is an attempt to deal with a lack of standard interfaces. Using an injected anonymous function, devs could design a function for their choice of language translator. And, the default injected interface could simply return the raw message.
That was my thinking -- I am trying to wrestle with how best to deal with those services used broadly across the application where there is no industry standard, no common interface. Of course, I could (and do within a package) create my own interface -- but as soon as I inject that interface into one of my packages, then I create a dependency to my interface. So, I've been looking for a way around that.

I am not entirely confident on this approach, but I think it might have potential for this type of service.

Thanks again for your review.

Yeah, I've had these same debates in my mind.

I've actually toyed with the idea of creating a "contracts" package that was nothing but interfaces - no implementation, which would then be used by most other packages. That gets you a common library of "contracts" without having to depend on all the implementation, etc. I do have a "Contracts" namespace in the Laravel 4 "support" package which is used by all other packages which is similar to that idea. I did something like this in my .NET days by creating a DLL that was strictly interfaces and it worked out pretty well for us. I still think that is a pretty good approach to dealing with this issue in PHP.

Anyways, something to think about.

Excellent. Oh boy! There is some very big potential for interoperability. I've been hoping you might be thinking that way. =)