我大概理解官方3.x编码风格大改的原因了

就拿position举例:

position在节点的属性面板里,是一个Vec3类型的属性

只修改position的x y z,不会触发该属性的set函数,必须赋值一个新Vec3才可以

为了避免用户误以为直接改x y z可以有效,还把position设置成只读属性

其他属性也是这个原因,都在各自的属性对象里,要整个替换才会触发set函数

这么写对Node底层代码来说,会比较优雅,比较安逸

但是

对用户来说就比较麻烦了,例如tween要分开来写

因此我做了一个基于3.x的节点扩展,让3.x也能兼容2.x的代码写法
https://blog.csdn.net/weixin_42714632/article/details/139001551

例如3.x里这么写也可以:
this.node.x++;
this.node.opacity = 100;
this.node.color = cc.color(255,0,0,0);
this.node.scaleX = 2;
cc.tween(this.node).to(1,{x:100,opacity:100,scaleX:2,color:cc.color(255,0,0)}).start();

4赞

得出个4.0版本,终极稳定版。

1赞

这个问题就是统一性和便捷性之争了。由于使用频繁,写起来是不太方便了

1赞

对,两个都支持,把选择权交给用户

1赞

好的规范会带来好的框架

1赞

改 prototype 啊。不是好的实践。

2赞

唯一的代价是规范有点晚,大家需要改变使用习惯。特别那些升级之后,没认真读文档的兄弟们就懵逼了

2赞

比如ts原生没有ValueType这个类,为什么cocos的库有呢,因为c#有。
为什么Vector3,Vector2要设置为readonly呢,因为c#的结构体是值类型,直接修改x,y,z修改的不是原来地址上的值,ts也要做到用户不能修改怎么办,设置为readonly啊。
更别提一些和unity api一模一样的命名和思路,举几个,SetSiblingIndex,BitMask
评价为:拙劣的用ts对c#以及unity进行cosplay。

尤其是我在代码注释里看到请用户注意缓存Vector2,Vector3的时,避免GC我就更难绷了。这玩意你交给用户去折腾啊?
Node节点自带x,y,z属性,并且可以直接修改或者直接position:Vector3就是可以修改x,y,z的,这是犯了什么天条么?
官方这么喜欢c#可以直接上车的,我也喜欢,不要cospaly。

楼主可以说说直接修改x,y,z怎么了,为什么对node底层代码更加优雅,安逸?
优雅在哪里,安逸在哪里

4赞

这跟unity里面的设置position一样,得一起设置才行

1赞

其实我觉得cosplay没问题,但是完全可以再套多一层来兼容2.x的写法,毕竟3.x的写法是真的一点都不优雅 :upside_down_face:

1赞

就是方便大家学完cocos,好找Unity工作。

Unity里你直接改x,y,z也不行啊。。。

unity直接改x,y,z不行的原因是因为结构体本身特性不支持,ts为什么要上这个特性?

1赞

你没认真读帖子

而且项目组都会写静态拓展方法支持修改x,y,z的吧

支持。和2.0也没关系,而是这种api纯纯增加用户使用的复杂度。

已转。只是每次c#编译的时候,就怀念cocos风一样的编译速度,做2d真爽啊。 :rofl:

我公司项目用Unity,我个人项目用cocos

比如,position属性在属性面板上是一个Vec3,而不是单独x,y,z三个数字
要让position属性发生变化,触发相应的逻辑(移动节点),就要修改该属性的set函数
但是position的x,y,z值发生变化,并不会触发position的set函数,因为position地址没有改变
必须把一个新的Vec3赋值给position,才会触发他的set函数
为了避免用户误以为设置position的x,y,z会触发节点移动,所以把position设置成只读
我写的扩展,是重新给节点定义一个x属性,修改x就会触发x的set函数,从而实现节点位移的逻辑。
其他属性也以此类推。
归根结底,两者各有优缺点。
3.x风格用新的Vec3覆盖position,适合多个坐标同时改变的情况。
2.x风格单独设置x,y,z,适合只改变一个分量的情况,另外tween写起来会比较舒服。
所以我选择,两者都保留,看情况选择用哪个。

我就是因为这个原因还在用 2.x,,