How to avoid many "use" namespace resolution calls

Asked

Viewed 58 times

1

I’m refactoring a small system in mvc that used the standard classmap to the psr-4, and was "obliged" to use multiple "use" within each controller to resolve the namespaces.

Example of what the classmap controller looked like:

use Particle\Filter\Filter; //biblioteca de filtro
use Rakit\Validation\Validator; // biblioteca de validacao de dados

class Teste extends Controller {

    function index () {

        $config = jsonConfig::get('dbconfig'); //classe qualquer

        echo '<pre>';
        print_r($config);

    }
}

Using the same controller with psr-4:

namespace App\controllers;

use App\core\Controller;
use App\models\config\jsonConfig;
use Particle\Filter\Filter;
use Rakit\Validation\Validator;

class Teste extends Controller {


    function index () {

        $config = jsonConfig::get('dbconfig');

        echo '<pre>';
        print_r($config);

    }
}

This is just an example, I have to do this in several controllers, models etc, there is some good practice to automate this, creating something like a Factory for controllers, for models etc, that already solves the generic namespaces of each "part" of the system.

Updating:

I also realized that I now need to use a backslash in calling native classes, e.g.: new PDO turned new \PDO

  • 1

    That one \ observation is to "exit" the current namespace. And what is the problem of several use?

  • It doesn’t seem like a practical thing, having to keep making the hand N use s, I don’t see that in frameworks

  • What frameworks? Everyone I know who uses Composer needs to use the namespace. Possible is but I find it unfeasible. An alternative is to create nicknames for the class in Composer, it does not remove, but decreases the size

  • Yeah, I know they do, I meant this long list of uses, it’s something more compact

  • In essence it is to make less complex codes. PHP is great for making simple code, but for some reason people have started to do more complex things than necessary. I think it’s because it’s fashionable. People don’t wonder what benefits it’s getting from complicating the code so much. What is not practical is to make MVC in simple codices. MVC has been created for extraordinarily complex applications.

  • I didn’t understand very well, I don’t think there is anything "complex" there, basically the principle of sole responsibility, so there are many USE

  • or it is better to continue with the classmap?

Show 2 more comments

1 answer

1

You can just not use the use and put the full namespace when calling functions, creating instances, etc:

namespace App\controllers;

class Teste extends Controller {

    function index () {

        $config = App\models\config\jsonConfig::get('dbconfig');

        echo '<pre>';
        print_r($config);

    }
}

However, as you can see, the namespace can be a bit large, and repeating it several times is not very interesting, in some cases may even be better, but few

Another option, which can be combined with the previous one, is to create nicknames, for example, a class that is in this namespace:

Foo\Bar\Baz\Qux

may be called through:

Alias\Qux

So you can call it the original form (long) and the new form (short), with a configuration similar to:

{
    "autoload": {
        "psr-4": {
            "Alias\\": "./Foo/Bar/Baz"
        }
    }
}

But the important thing is Why do it differently? In most languages you have some kind of import, which is similar to PHP namespaces, for example, a control class of a simple CRUD with the Spring ecosystem starts like this:

package com.example.controller;

import java.util.List;
import java.util.Optional;

import javax.validation.Valid;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.CrossOrigin;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.server.ResponseStatusException;

import com.example.model.MyModel;
import com.example.repository.MyRepository;

The structure is quite similar, no?

Namespaces are good, help organize third-party code, makes problems with similar classes and filenames difficult

Browser other questions tagged

You are not signed in. Login or sign up in order to post.