【问题标题】:PHP defining namespaces on composer's vendor packagesPHP 在作曲家的供应商包上定义命名空间
【发布时间】:2014-10-23 06:48:27
【问题描述】:

我在 PHP 中遇到了一些命名空间问题。

我已经确定了一切,并在我的项目中工作,这一切都运行良好。我使用 composer 的自动加载功能来自动加载我所有的项目类。

最近我需要通过作曲家为 securimage(验证码应用程序)引入一个依赖项。我遇到的问题是,在我编辑文件并在每个 php 脚本的顶部插入以下内容之前,它无法工作。:

<?php namespace vendor\dapphp\securimage;

我的 composer.json 文件正在使用 PSR-4,如果这有助于确定我哪里出错了。

"psr-4": {
            "vendor\\dapphp\\securimage\\": "vendor/dapphp/securimage"
        }

我的问题是,如果我不明白如何引入作曲家供应商项目并让 PHP 自动插入/理解这些应该放在命名空间下

vendor\{userid}\{projectid}

无需编辑其中的实际文件。

我确定我错过了 composer.json 文件中的某些内容?

【问题讨论】:

    标签: php namespaces composer-php


    【解决方案1】:

    你并没有真正错过任何东西。由包来命名其源代码。除非源代码字面上包含namespace 声明,否则代码位于全局命名空间中。如果不更改所有涉及的源代码,您就无法更改这一事实。 Securimage 代码没有命名空间,句号。

    "psr-4": {
        "vendor\\dapphp\\securimage\\": "vendor/dapphp/securimage"
    }
    

    这只是配置自动加载器。意思是,如果您尝试在命名空间vendor\dapphp\securimage\... 中加载一个类,Composer 的自动加载器知道在哪里可以找到它。它不会将代码放在此命名空间中。

    【讨论】:

    • 感谢您回答 deceze。那么,当他们决定为他们的项目命名并且我已经确定了在全局命名空间中解决他们的类时会发生什么?
    • 那么你将不得不更新你的代码。 :) 将某些东西放入命名空间基本上与重命名所有内容或更改函数签名相同。它必然会破坏向后兼容性,并且没有真正的方法可以避免它。
    • 我认为使用命名空间是正确的。我没想到最终会遇到第三者阻碍我自己的项目。他们真的没有很好地处理这个命名空间的事情,因为这感觉就像是最后一分钟的黑客攻击。我想我会分叉项目并更新他们的代码,所以至少我可以控制它。非常感谢,您已经满足了我的问题 - 非常感谢! :)
    • 或者,你知道,只使用没有命名空间的第三方库。如果其他所有内容都是命名空间的,那么这不太可能成为问题。如果他们确实更新以使用名称空间,那么您会弄清楚的。比必须维护一个分支并不断包含上游补丁要好。
    • 我想首先引入命名空间的版本将作为新的主要版本发布,因为它破坏了兼容性(更改命名空间和类名是不兼容的接口更改)。期待一个新的 X+1.0.0 版本,或者一个全新的包名称。
    猜你喜欢
    • 2014-04-27
    • 1970-01-01
    • 2016-08-30
    • 2018-09-11
    • 2015-02-02
    • 2016-06-15
    • 1970-01-01
    • 2016-12-18
    • 1970-01-01
    相关资源
    最近更新 更多