Answers:
我可以肯定地说99.9999%,WordPress在将来的版本中永远不会完全变成OOP,其中最重要的一点是该主题一次又一次地出现在wp-hackers列表上,并且核心团队成员对此表示不感兴趣。这样做。
从1990年左右开始我在编程和教授OOP方面的个人经验时,我同意核心团队的观点,并认为完整的OOP是一个错误。尽管我曾经是OOP狂热者,并认为OOP是灵丹妙药,但此后我开始相信OOP在某些情况下具有其价值,但在其他情况下却会阻碍其发展。
我在OOP中发现的最大问题之一是,它迫使开发人员在开发人员真正了解该结构是什么之前就烘烤了结构,从而导致了脆弱的基类问题。
当然,对于WordPress的某些特定方面,OOP很有道理,如果您学习核心课程,就会发现此类。Widget
,List_Tables
(在3.1中)等。
在这一点上,我很高兴在非OOP范式中使用WordPress,并认为如果是纯OOP,则WordPress永远不会获得它的支持。为什么?因为OOP可能会增加潜在的WordPress主题和插件开发人员的复杂性,并且可能会导致应用程序不够灵活,无法随着核心团队过去对用户需求的更多了解而发展。 6年
FWIW。
每个新版本中,许多WP组件都用OOP代码重写,并且新组件倾向于使用它(例如,WP_Customizer
东西)。但是,如果您要问WP是否会将其体系结构更改为完全面向对象的体系结构,那么否,那么目前没有任何信息表明这种情况。
我不会说它永远不会发生,但它不太可能在不久的将来发生,并且可能不是因为“基类”问题:)
首先,对于像WordPress这样的CMS应用程序,在OOP上使用过程代码仅存在缺点,仅因为此类应用程序是通过插件扩展的。混合使用函数和全局变量并不会使此操作变得简单。在编写WP时,没有人能预料到WP会变成什么样,因此做出了许多错误的选择。现在很难赶上,因为大多数插件和主题都将无法正常工作。实施一个巨大的兼容性层来避免这种情况可能会减慢WP的速度,并在开发人员之间造成更大的混乱。还考虑目的-减轻开发人员的生活,但要由用户承担费用吗?
如果有帮助的话- 关于wp-hacker 的非常古老的讨论,但仍与此主题相关,以及社区提出的想法,现在标记为“插件领域”。我最近没有注意到这个方向的其他活动。