是否有必要引入对 namespace 的支持

是否有必要引入对 `namespace` 的支持

同标题

新需求操作步骤

autoload 功能支持 namespace 类

为解决问题做过哪些尝试

初始方案：

底层自行实现对符合 PSR4 的 namespace 的支持，并定义基准目录和命名规则
引入 composer 来提供对 namespace 的支持（引入 composer 不意味着要使用第三方类库）

其他信息

其它可行性方案可群策群力

这个以前讨论过，不好搞啊……
个人感觉暂时是引入不了的，除非Discuz未来能整体按namespace模式进行改造。
不过这么改破坏性也挺强的，对插件影响也大，差不多比得上Discuz到Discuz X的迁移规模了，以Discuz的现状不一定能承受得了这么大的改动

前一阵考虑过能不能先来个小目标，把UCenter整体搞上namespace，但发现也不是太好弄

其实两种方案是可以并存的。一些基础类库或者功能模块可以先改造，dz原 autoload 托底。这样影响应该会比较小。

托底就意味着文件里不能加namespace啊，加了原来的调用方式就不能用了，那最终还是没有namespace的。
总不能每个class都复制2份吧？

感觉你对这个理解上有问题。
比如引入 composer 为例，先是由 composer 的 autoload 解决类加载，composer 找不到会转交给下一个 autoload 加载器，这个指的是 dz 的 autoload ，dz 的再找不到就要报错了

spl_autoload 是可以注册多个的

不是我理解的有问题，举个例子，假设给class seccode加入namespace discuz，那就意味着你用原方法调用class seccode的时候，哪怕兜底的autoloader成功引入了class seccode所在的文件，依然会调用失败，因为class已经在namespace下面了，直接new seccode不好使了

这一部分是需要兼容的。不过可以保留声明，在这个里面调用带 namespace 的

这没法兼容啊，除非创建2套文件，但那也太恶心了

兼容过渡肯定是需要支持的。一次性架构调整很不现实。而且重写之前老文件的话，老文件可以最小化，相关入口通过实现 __call 或者 __callStatic 来转移到 namespace 类上是可以搞的或者继承 namespace 类

namespace 涉及的改动比较大但暂时看不到什么好处，X3.5 大概率不会上。
后续有什么关于改造必要性的反馈或者一些技术细节之类的可以以这个 Issue 做统一反馈节点。
也麻烦官方对这个 Issue 保持开启，不要修改为关闭或者拒绝，谢谢。

除非整体按namespace模式进行改造，兼容没优势

之前想提过类似的，我的想法大概是对存量代码进行大规模 namespace 化改造是没有必要，但是要是能自带支持 composer 是极好的，因为几乎任何二次开发都得先过 composer 关。将来 discuz 自己说不定也需要，或者说打通这个之后至少就没有必要去“避讳“使用三方模块了。不像现在所有东西即使生态里有，dz还是想自己实现一遍...

我上次折腾的时候大致上参照的这篇
http://isunman.com/2021/04/23/Discuz-X3.1-uses-Composer-to-install-third-party-libraries/
它用 composer 的 autoload 替代了 dz 原有的，然后用 classmap 那个机制自动扫描了一下 dz 代码就能用了。

不太清楚细节原理但是... 如果这套方式真的能用的话，就可以通过这个方式引入一个空白的 composer 工程，用户需要二开的话就自己装，不需要也不会碍事。代码量不但不会增加还会减少。

Discuz / DiscuzX

内容风险标识