New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Importing and aliases vs. fully qualified namespaces #872

Closed
ldusan84 opened this Issue Dec 25, 2014 · 4 comments

Comments

Projects
7 participants
@ldusan84
Collaborator

ldusan84 commented Dec 25, 2014

I think that Magento2 should import namespaces and use aliases instead of using fully qualified namespaces all over the place.

Here is an example.

What I suggest is that instead of:

throw new \Magento\Framework\Model\Exception(
    __('Invalid login or password.'),
    self::EXCEPTION_INVALID_EMAIL_OR_PASSWORD
);

We could have:

use \Magento\Framework\Model\Exception as MagentoException
/* ... */
throw new MagentoException(
    __('Invalid login or password.'),
    self::EXCEPTION_INVALID_EMAIL_OR_PASSWORD
);

Here are the benefits from this:

  1. With importing namespaces keyword at the first few lines of a class you actually get a nice documentation of your class dependencies. Everything that class uses is in those first few lines. It makes dependencies explicit.
  2. If something changes in the future, you would only need to change it in one place, in import declaration and the alias remains. With fully qualified namespaces you would need to find them everywhere in class and change.
  3. Less confusion if you have similar namespaces, you can give them different aliases.
  4. All major frameworks use importing/aliases over fully qualified namespaces.

Let me know what you think.

@orlangur

This comment has been minimized.

Contributor

orlangur commented Dec 25, 2014

I totally second the importing approach 👍

use \Magento\Framework\Model\Exception as MagentoException
Less confusion if you have similar namespaces, you can give them different aliases.

I would rather forbid aliases usage or allow them only for exceptional cases. Proper class name must contain all data necessary to understand the purpose of class. There are a lot of names with directory-per-word approach and would be better to rename classes than introduce aliases each time you want to use them, for instance:
Magento\Framework\Model\Exception -> Magento\Framework\Model\ModelException
Magento\Catalog\Model\Resource\Product\Collection -> Magento\Catalog\Model\Resource\ProductCollection
So that classes could be imported without aliasing.

You may notice that there are a lot of code in Magento2 using short names already. But in code which was not changed for a long time there are still a lot of fully-qualified class names. Would be nice to replace fully-qualified class names with imports all over the code and enforce short name usage with static test (for example, check that T_NS_SEPARATOR token does not appear outside the namespace and use statements; or some more sophisticated check if we want to allow relative class names).

What tool would you suggest for such transformation? The closest ready-to-use utility I found so far is PHP Refactoring Browser, but "optimize use statements" feature here does not work as expected: type-hinted class names in constructor/other methods, PHPDoc blocks are not updated.

So, except the IDE abilities which I didn't analyze, I would build such script using one of:

@ldusan84

This comment has been minimized.

Collaborator

ldusan84 commented Dec 25, 2014

Thanks @orlangur for the comment.

I just picked that Exception class for no reason, and yes I should have made a better alias, but for me even importing without alias is still better than fully qualified name. Maybe aliases could be used only if we have two classes with the same name.

To tell you the truth, I am not sure which tool would be the best to do this automatically. I know some IDEs can do that, but I am not sure how reliable are they. I guess it would be hard to find a reliable tool.

@verklov

This comment has been minimized.

Contributor

verklov commented Jan 5, 2015

Internal ticket: MAGETWO-32347

@piotrekkaminski

This comment has been minimized.

Contributor

piotrekkaminski commented Aug 30, 2016

Thank you for your submission.

We recently made some changes to the way we process GitHub submissions to more quickly identify and respond to core code issues.

Feature Requests and Improvements should now be submitted to the new Magento 2 Feature Requests and Improvements forum (see details here).

We are closing this GitHub ticket and have moved your request to the new forum.

mmansoor-magento pushed a commit that referenced this issue Feb 26, 2017

Merge pull request #872 from magento-performance/s4
[Performance] Performance Profile Generator

@magento-engcom-team magento-engcom-team moved this from TODO to Done in branch [2.3-develop] Sep 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment