const {ccclass, property} = cc._decorator;
@ccclass //how to do the same thing in haxe?
export default class NewClass extends cc.Component {
@property(cc.Label) //how to do the same thing in haxe?
label: cc.Label = null;
@property({
visible: false
})
}
cc.Class({
extends: cc.Component,
properties: {
label: {
default: null,
type: cc.Label
},
// defaults, set visually when attaching this script to the Canvas
text: 'qestion'
},
// use this for initialization
onLoad: function () {
this.label.string = "1";
},
// called every frame
update: function (dt) {
},
});
I’ve fixed a related issue in dts2hx, so if you upgrade to 0.11.7 and reconvert you can import the decorators as functions with import global.cc._Decorator.*;
import global.cc._Decorator.*;
import global.cc.Label;
import global.cc.Component;
import global.Cc;
class Main {
static function main() {
ccclass(Cc.Class({
'extends': Component,
properties: {
label: property({
'default': null,
type: Label,
}),
},
onLoad: function() {
var this_ = js.Lib.nativeThis;
this_.lable.string = "1";
},
update: function (dt) {
},
}));
}
}
Maybe you could make a macro to enable using the decorators like @property { ... }
em,although you fixed that.base issue.but there are lot’s of API use es6 declared
like @example
```js
// get sprite component.
var sprite = node.getComponent(cc.Sprite);
// get custom test calss.
var test = node.getComponent("Test");
```
*/
getComponent<T extends Component>(type: {prototype: T}): T;
I can’ t call that function like
node. getComponent(cc.Button);//wrong in haxe..but work in typescript.
cc.Button is a class in haxe, in the type-definitions it looks like they identify classes as an object with a prototype field. In haxe the js-prototype field isn’t exposed and so cannot be used for unification
Not much we can do about it in the converter other than pattern match for {prototype: T}, but I think it’s a sufficiently small edge case as not to be worth the effort
Edit: Maybe I could add a @:noComplete var prototype:T to all generated classes, which may remove the need for a cast
You mean add a macro abstraction that generates metadata that could apply the decorators? If that could somehow be generalized, i.e: a metadata + args generated for each decorator, it’d be neat indeed. The specifics might be harder though.
@haxiomic Do you think something like that would be possible?
It could be implemented as compiler-macro that searches for expressions and types with decorator metadata and applies ast transformations or tweaks js code-gen
It’s a big project and I don’t have spare much bandwidth this summer so I’ll let someone else take that batten