Open eduardo-costa opened 8 years ago
The issue here is that we can't access the length
field without get/set anymore and we still need to do that. Or is there a way?
What we could do is support @:property
, similar to how it's done in C#: only for get,set
, get,never
, never,set
properties without @:isVar
, so there's no physical field.
My current workaround is
public function new()
{
untyped Object.defineProperty(this, "length", { get: this.get_length, set: this.set_length });
}
So basically the get_
and set_
versions still exists (for Reflection) and the ES5 versions are injected
I'm just afraid of possible performance implications of doing such in each new instance.
The issue i was talking about is this:
class C {
public var a(get,null):Int;
function get_a() return a;
}
Here we need the physical a
field, so we can't just generate js properties by default, but explicit @:property
thing described in https://github.com/HaxeFoundation/haxe/issues/5104#issuecomment-208752587 could work.
I'm cool with manually pointing which ones to have this behaviour!
The reason is I have a really complete Math lib for Haxor which would be cool to use as a compiled javascript lib and embedded on the page.
I'll stick with the Object.defineProperty
workaround until 3.4 then.
I think I'll look into this after 3.3.
Thanks!
I think you can support properties on prototype via __init__
magic method
Will check on that! Thanks!
Worked!
@:expose
class Vector4
{
static function __init__():Void {
#if js
untyped Object.defineProperty(Vector4.prototype, "length", { get: Vector4.prototype.get_length });
#end
}
/*...*/
}
Not sure why having a physical field is a problem? If it's just name shadowing could we not mangle the physical name?
Can we have the get/set features of ES5? It will allow javascript libs to be compiled and used outside the Haxe scope.