PHP Namespaces Override Use Statement - php

Can anyone tell me if it's possible to override a use statement?
My example is having an MVC setup where there is core code with the ability to override each Controller / Model with a custom version that extends the core version.
The issue I face is that my core controller has a use statement telling it to use the core model, so if I extend the model, I'm not sure how to tell it to use the custom model rather than the core one
I could obviously update the core controller use statement to point to the custom one, but the core code is shared so the custom version may not exist on other sites that use this core core
Use statements are obviously file level so I'm guessing it's not possible, but I'm hoping there's either something I don't know about or maybe a workaround
Example
Core controller
namespace Core;
use Core\Model\Example as ExampleModel;
class ExampleController {
public function output() {
$model = new ExampleModel;
$model->test();
}
}
Core Model
namespace Core;
class ExampleModel() {
public function test() {
echo 'This is the core test';
}
}
Custom Controller
namespace Custom;
use Custom\Controller\Example as Base,
Custom\Model\Example as ExampleModel;
class ExampleController extends Base {
//Inherits the output() method
}
Custom Model
namespace Custom;
use Core\Model\Example as Base;
class ExampleModel extends Base {
public function test() {
echo 'This is the custom test';
}
}
So given this example, is it possible for me to create an instance of the custom controller which uses the custom model to output 'This is the custom test', without modifying the core code at all?
Hopefully what I'm asking makes sense
Thanks

I'm not quite sure I understand your question, but the answer should be self-evident: If your custom model extends from the core model, you can simply extend another class from that custom class
If you are writing code, that depends on a child of the core class being present, then that child class becomes a vital part of your project. If you can't change the core itself, add that class as a dependency. It's as simple as that.
Adding a second layer of inheritance needn't worry you, it's perfectly common to do so. Something like this is perfectly predictable, and reliable:
namespace Core;
class Model
{
public function coreTest()
{
return 'from the core';
}
}
namespace Custom;
use Core\Model;
class CustomModel extends Model
{
public function customTest()
{
return 'from the custom model';
}
}
//finally
namespace Project;
use Custom\CustomModel;
class ProjectModel extends CustomModel
{
public function test()
{
return array(
$this->coreTest(),
$this->customTest(),
'From the project'
);
}
}
$test = new ProjectModel();
echo implode(PHP_EOL, $test->test());
If, however you want a given class to extend from another class, based on whether or not that class exists, you are looking for conditional imports.
A simple use statement is evaluated at compile-time, so there's no way you can use an if check to switch between which class you extend from.
There is, however a hacky work-around, but I wouldn't rely on it. Check if the given class exists (without autoloading), and set an alias to the class that does.
if (!class_exists('\\Custom\\Model', false))
class_alias('\\Core\\Model', 'Base');
else
class_alias('\\Custom\\Model', 'Base');
class CustomModel extends Base
{}
But really: don't go down this route. Sure your code will work, but if you then rely on a method being available, that was defined in the custom class, but that class was missing, then your code will fail... horribly.
Details on conditional imports:
Why use class alisases?

Related

Implements Interface only if exists?

I'm trying to find a way to implement an Interface only when this Interface is available.
The Interface in question is
PrestaShop\PrestaShop\Core\Module\WidgetInterface
From Prestashop. It's used in a module.
The thing is, in order to be compatible with multiple version of Prestashop, the code must handle the case where WidgetInterface does not exists.
I was thinking in testing the existence of the interface and import it after, like this:
if (interface_exists('PrestaShop\PrestaShop\Core\Module\WidgetInterface')) {
use PrestaShop\PrestaShop\Core\Module\WidgetInterface
} else {
interface WidgetInterface {}
}
But of course, it's not possible to use use inside a if statement.
I then tried to do some try/catch, but that's the same issue (too bad it's not Python).
How can I do to implements WidgetInterface only when available?
You can't implement an interface dynamically, like you say, but you can write your own interface and only require it if the other does not exist.
Ie: your interface would be something like widget_interface.php, or whatever you want to call it, as long as it's not PSR-0/4 compliant, or autoloaded in whatever way you normally do.
<?php
namespace PrestaShop\PrestaShop\Core\Module;
/**
* This is the replacement interface, using the same namespace as the Prestashop one
*/
interface WidgetInterface
{
}
Then, in your class, you can do the following:
<?php
namespace App;
if (!interface_exists('\PrestaShop\PrestaShop\Core\Module\WidgetInterface')) {
require __DIR__ . '/path/to/widget_interface.php';
}
class WhateverClass implements \PrestaShop\PrestaShop\Core\Module\WidgetInterface
{
}
Your replacement interface will only be loaded if the Prestashop one doesn't exist.
True, you can't put use inside an if block, but use merely sets up an alias for the class. It doesn't attempt to load the class. So it can safely be outside the if block.
And you can define the class or interface itself inside an if.
This is how Symfony dealt with this exact issue, inheriting from an interface that may not exist:
namespace Symfony\Contracts\EventDispatcher;
use Psr\EventDispatcher\EventDispatcherInterface as PsrEventDispatcherInterface;
if (interface_exists(PsrEventDispatcherInterface::class)) {
interface EventDispatcherInterface extends PsrEventDispatcherInterface
{
public function dispatch($event);
}
} else {
interface EventDispatcherInterface
{
public function dispatch($event);
}
}
Personally, to keep things clean and contained in one spot, I would define your own interface like this that inherits from the PrestaShop interface if available or else provides its own implementation, and then have your class inherit from that.

Laravel use Trait methods in another Trait

Normally I have a question about something not working, now I have a question about something that IS working, I am just confused as to why. This is the structure that I have in Laravel:
ExampleController
use App\Http\Traits\Trait1;
use App\Http\Traits\Trait2;
ExampleController extends Controller {
use Trait1, Trait2;
public function index()
{
// I can use methods from Trait1 and Trait2 here, works fine
}
}
Trait1
namespace App\Http\Traits;
trait Trait1 {
exampleMethodTrait1()
{
}
}
Trait2
namespace App\Http\Traits;
trait Trait2 {
$test = $this->exampleMethodTrait1();
}
Calling a method defined in Trait1 from Trait2 actually works, while I have not added use App\Http\Traits\Trait1; in Trait2. Is that because they are both loaded in the controller?
Okay, Let me put same code and explain you why it is working.
Trait1
<?php
namespace App\Http\Traits;
trait Trait1 {
public function exampleMethodTrait1()
{
echo 'okay';
}
}
?>
Trait 2
<?php
namespace App\Http\Traits;
trait Trait2 {
public function bar() {
var_dump(get_class($this));
$test = $this->exampleMethodTrait1();
}
}
?>
MyController
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use App\Http\Traits\Trait1;
use App\Http\Traits\Trait2;
class MyController extends Controller
{
use Trait1, Trait2;
/**
* Show the application dashboard.
*
* #return \Illuminate\Http\Response
*/
public function index()
{
$this->bar();
}
}
Now, if you will notice in Trait 2, var_dump(get_class($this)); $this is instance of MyController and not instance of trait 2, that is how it is working and it is expected behavior.
Now if you want to know if you can use one trait in side another
YES
You can do like
TaraitA
Trait A {
}
TraitB
Trait B {
use A;
}
And it will work fine.
Yes, they are both loaded in your controller as a part of it therefore they have access between them also controller methods
See the example 4
https://www.php.net/manual/en/language.oop5.traits.php
Regards
I think your confusion comes from believing that the $this inside a trait corresponds to the trait itself. But it is not.
Traits are nothing by themselves: they exists only in the context of a real class, as a helper to copy-paste methods around but not visually polluting your actual classes.
The $this you use to call exampleMethodTrait1 is not an instance of Trait2 (nor Trait1) but an instance of ExampleController, that has copied the methods over from the traits.
This doesn't happen only with traits, though, but also with parent classes in the hierarchy:
Example
abstract class Base {} // First level of inheritance
class Building extends Base {} // Second level of inheritance
class House extends Building {} // Last level of inheritance
$this (and static) always corresponds to an instance of the most concrete class of the hierarchy (the last level of inheritance).
self instead refers to the actual class instance (the same level of inheritance where the method is defined). Still never a trait, they cannot be instantiated by themselves.
the traits are not part of the hierarchy, but blindly pasted where you use them.

Use Imported Classes From Parent Class In a PHP Trait Laravel 5.5

I'm currently working on a PHP trait thay will help me to reuse code in some class controllers that I have using Laravel framework.
I wanted to make the trait methods as dynamic as I could but when trying to access to a class that my parent class imported, I get a Class not found exception.
My class controller is as follows:
namespace App\Http\Controllers\Admin;
use App\Models\ {
Curso,
Leccion,
Diapositiva,
ImagenDiapositiva
};
use App\Traits\TestTrait;
class DiapositivasController extends Controller{
use TestTrait;
public function addRecord(Request $request){
$request->class_name = 'ImagenDiapositiva';
$this->addImage($request);
}
}
My Trait:
namespace App\Traits;
trait TestTrait{
public function addImage($request){
$class_name = $request->class_name;
$diapositiva = new $class_name;
//extra code
}
}
So my doubt is, do I have to include the model classes I want to use inside my Trait again or am I doing something else wrong?
if you use new with a variable class name, you have to use the fully qualified class name. I'm guessing new $class_name is the root cause of the issue here, since $class_name would have to be something like: 'App\Models\ImagenDiapositiva' or whatever the full namespace is. Just have to change the call $request->class_name = 'ImagenDiapositiva'; to reflect the full name of the class.

PHP OOP abstract classes subclass registration

I have an abstract question for you.
Question:
How can a subclass that extends an abstract class register itself to the abstract class or another class?
Problem:
Guess we have a module master named ModuleMaster and maybe someone else writes another modules to handle a specific problem without modifying the master class and named it ModuleA. For that reason we want to implement a dynamic loading of problem solutions.
My idea:
File: Extensions.php:
namespace Project\Extensions;
class Extensions
{
public function getLoadedModules()
{
var_dump(ModuleMaster::LOADED_MODULES);
}
}
File: Modules\ModuleMaster.php:
namespace Project\Extensions\Modules;
abtract class ModuleMaster
{
public const LOADED_MODULES = array();
}
File: Modules\ModuleA.php:
namespace Project\Extensions\Modules;
class ModuleA extends ModuleMaster
{
}
I hope you understand what I mean and can help with that abstract problem.
This is very strange to use. It's probably a better design to have an external registry for your module. But I think you're asking for this:
File: Extensions.php:
namespace Project\Extensions;
use \Project\Extensions\Modules\ModuleMaster;
class Extensions
{
public function getLoadedModules()
{
var_dump(ModuleMaster::getLoadedModules());
}
}
File: Modules\ModuleMaster.php:
namespace Project\Extensions\Modules;
abstract class ModuleMaster
{
public static function getLoadedModules() {
$parent = self::class;
return array_values(array_filter(\get_declared_classes(), function ($class) use ($parent) {
return in_array($parent, class_parents($class));
}));
}
}
File: Modules\ModuleA.php:
namespace Project\Extensions\Modules;
use \Project\Extensions\Modules\ModuleMaster;
class ModuleA extends ModuleMaster
{
}
Example use:
$e = new \Project\Extensions\Extensions;
$e->getLoadedModules();
Example result:
array(1) {
[0]=>
string(34) "Project\Extensions\Modules\ModuleA"
}
Please note that the code only works if all your class files are included into the context before running getLoadedModules(). PHP won't know your class exists if it is not already loaded into the context.
You seem to be trying to create a capability in the parent class which is not required or inappropriate in the child class. This is the opposite of inheritance and hence an anti-pattern. Further, even though it might be considered as an extension of reflection, you are trying to put runtime data in a class - that's not what classes are for.
You've also not explained in any way that I can understand why you want to do this.
I suspect you really want to implement a factory, strategy or a registry object.

Use statement for child classes

I have a Controller class in which I have to use several namespaces like :
<?php
use Respect/Validation/Validator;
use Blah/blah/Foo;
class Controller {}
Now what I want that in every controller files that extends my Controller class, I do not have to write the use statements again and again.
This is something I want similar to what Laravel has done in his alias section.
How would I achieve this thing ? So for example when I do :
<?php
class HomeController extends Controller {
public function index()
{
$data = '';
Validator::arr($data); // Validator not found
}
}
This is unfortunately what you would have to do if using static methods. You could also have a Controller method (the constructor even) to inject the validator into the class, which the child classes can then use. You would the use public instance variables on the validator.
The benefit is that you do not need to specify the NS for your dependencies again and, especially so, your code is cleaner since you do not have a hard dependency on the Validator class.

Categories