我们之间的讨论肯定是我们之间定标准，我又不是再跟官方讨论并质疑他们的标准，官方也没有回复我为啥不加这个接口以及是否加这个接口
如果你是基于“官方肯定有自己的标准，官方这么做肯定有官方的道理”这个猜测为基础来跟我讨论为啥官方不加这个接口，那没有意义，请先证实这个猜测的正确性，但言语间你显然只是猜测并且说自己不知道官方的真实目的
那你在前面的一系列跟我的讨论只能基于你定义的标准或者你的想法来跟我讨论，基于此，我自然要先弄清楚你的标准或者你的想法是否符合我的标准和我的想法，如果我们对标准的定义都不一致，那有啥可讨论的呢，而且我的标准我在上面的回复中已经反复而且清晰的提到过，所以我说我们之间是“没有标准的争论”有何问题？
OK，这里可以说是我的理解问题，我以为你是指这个划分没有标准，而不是没有划分标准的数据/方法 支持
这也相当搞笑，且不是我没有明确表达是否认可你的联想，即便我不认可，有怎么能得出“没有联想能力”这个结论呢，这也并不是什么高明的联想吧，游戏引擎组件设计基本都是“组合模式”，这种模式设计中有清晰的定义的东西无需任何其他的比喻来再次说明一次
嗯，所以你说的这句话是对的，我们应该把所有属性都放在 node 里面
所有有经验的程序员都是从没有经验的程序员过来的，自然能知道没有经验的程序员中的自己这个类型是什么样子的
嗯，所以我说的是错的，现在论坛一大堆新人反馈找不到自己想要的属性
你这是典型的谬误滑坡，我之前把所有属性都单独做成组件的假设就是为了让这种谬误滑坡显性化来表明这种想法是错的，所以你这句反讽却是用错地方了，我们在这点上没有分歧，都不应该谬误滑坡，而是就事论事
我说个，node有哪些属性是取决于node是什么的，我不认为加上opacity和size两个属性node的属性就爆炸了，如果定义清晰，找不到想要的属性也很奇怪，我从1.x用到3.x也没觉得node的属性数量有剧烈的增减，常用的属性就那么几个，不常用的一下找不到跟设计没有关系，任何设计下不常用的属性都很难找到，分了组件还得自己自己要的属性在哪个组件里，岂不是更难找到
这个只针对node的属性来说，毕竟现在官方也没公开发表说明有多少新人吐槽找不到node上的对应属性，这些属性是哪些，为啥找不到，这些新人占整体新人的比例是多少，是否需要为了这些新人而做出改变
个人倒是希望引擎官方可以在新建节点时提供一个下级对话框，让用户做一些基本的配置（最好是此配置面板可以开放接口做插件），比如创建node可以选择直接添加UITransform和UIOpacity什么的，创建ScrollView的时候可以直接添加用户自定义的addItem乃至addWeapon接口……
最后针对标题我再回复一句，2.x 的 childrenCount 在 3.x 已经没了
UITransform和UIOpacity这两个组件太特殊了，作为node的属性存在会在使用时更加方便也更加自然，毕竟一个节点没有大小和透明度那这个节点是什么就很难说清了。
UITransform可能是出于一些设计做出的妥协吧，node有Scale和Rotation却没有Size，总感觉奇怪。
UIOpacity我觉得应该是临时性的，可能目前有些问题还没解决，因为Color中有透明度选项，而Color又更多跟渲染组件绑定而不能作为node的属性，导致不好协调。
至于ScrollView我觉得官网出一个新的组件专门做背包类功能更好点，https://github.com/gh-kL/cocoscreator-list 这个库我觉得就特别好，可惜官方没吸收，靠作者维护在Creator升个版本就大改一次的强度下，很难跟上最新版本
如果创建一个组件需要做选择还是挺麻烦的，就像现在创建一个组件给了个改名机会必须多一步操作改变焦点才能创建出来这种画蛇添足的修改就用着挺难受，官方可以提供创建模板给用户自定义创建过程可能更好点
现在好像无法扩展层级管理器菜单，期待一个引擎官方开放层级管理器菜单扩展吧，消息里现在貌似也缺少获取选中节点的接口不好通过主菜单简单实现
哎，官方有很多基础设施一直没做好，也不愿意收编有潜力的第三方，tiledmap都多少年了也是大小问题不断，希望后面的更新能完善吧。
到现在引擎的运行预览环境主要还是浏览器，但就是不愿意把运行时的节点树加上，第三方插件不是收费就是跟不上Creator的版本，3.x一来多少好用的插件瞬间归零。unity一开始就有的东西Creator这么多年都没有，还是不重视。
第三方插件如果是购买内容用户无话可说，可是像运行时节点树，状态机行为树编辑 这些基础设施都要花几十到几百去买插件用，这个生态就显得很畸形。官方应该花钱收编，而不是把成本转嫁到用户身上
cocos可以说是压根没向下兼容生态，也就是cc只要不停的这样升级，到最后也是0生态！懂的人都懂
没办法，主要还是穷吧，白鹭已经穷死了，laya也是半死靠死贴刷元宇宙概念跪舔资本勉强苟活，cocos可以说已经是当前最专注于引擎和编辑器本身的国产引擎团队了，然而最大的问题也是在国内目前的环境下有效的盈利模式还是个谜……
Unity不可鉴啊，在虚幻的冲击下Unity也活的不咋地现在，相对虚幻的财大气粗这会儿也肉眼可见的力不从心，现在个人倒是挺期待某天valve收购Unity，腾讯或者网易之流收购cocos大力包养之类的（狗头
你可能之前接触过其他的引擎或者UI框架有这种方法吧，一般additem这种接口，通常item都是一样的，例如laya的list,当然fgui的list可以动态指定，不过说到底都是对addChild进行了一种上层封装。想表达的是，工具的提供者不需要去满足所有的具体需求，引擎提供的接口可以让使用者自己通过二次封装实现需求就已经是一款好的引擎了。by the way，你不知道怎么自己加吗？
1赞
对于你的问题以及我为何希望加这个接口，我上面已经有过清晰的表达
我不仅知道怎么加，我还知道怎么自己写一个组件，大家都是程序员，只要智商没问题肯花时间甚至自己写一个游戏引擎也没啥问题
所以我只是从我的需求出发提供一个个人使用上的建议哈，并不是每个人都会遇到同样的问题和有同样的困惑，但我遇到了，而且我写了完整的理由
ScrollView既然强行绑定了一个content属性，我个人的理解是添加一个addItem的接口也没啥不可，否则我觉得强行添加一个content属性都是多余的，当然，大家习惯不同理解不同需求不同也都正常哈
我还真的不知道怎么自己加，尤其是加了之后，怎么让进度条能够匹配。如果我默认的长度是显示进度条的，结果我实际的list长度是0， 我不知道应该怎么关闭进度条，反过来我不知道怎么显示进度条，所以说到底，scrollView真的有用吗？基本需要自己二次封装，不然没啥卵用。
你咋天天和人吵架
这不是吵架，这是探讨，而且有人无意有意的嘲讽你，你不管吗