@:native metadata on typedef fields

[zabojad]

I'm trying to use the @:native metadata on a typedef field:

typedef MyStruct = {
    var field01 : String,
    @:native('package') var pack : Dynamic
}

But the @:native metadata doesn't seem to work on typedef fields... That would be very useful in js when interfacing with extern libs...

[ibilon]

Native only work on externs, though I'm not sure you can do an extern typedef.

[back2dos]

I can confirm I have needed this on occasion. My workaround was to declare an abstract that would then do the mapping in its accessors. Not very concise to say the least.

On Tue, Apr 12, 2016 at 11:37 AM, Valentin Lemière <notifications@github.com

wrote:

Native only work on externs, though I'm not sure you can do an extern typedef.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/haxe/issues/5105#issuecomment-208817144

[nadako]

Yeah that's what everyone does right now. I think @fponticelli or someone even has a macro builder for those. Related discussion: #2185

[zabojad]

So to sum it up: can the @:native metadata for typedef fields be implemented in Haxe or not?

I do think it has all its meaning as when writing and using externs, you often have to describe data structures used for the parameters of externs methods. We do not have more control over the names used for the fields of those structures than for the extern methods names... Thus the need of this feature for typedef fields as well...

[zabojad]

2185 is a bit messy as it actually tries to address several issues in a single ticket...

[nadako]

So to sum it up: can the @:native metadata for typedef fields be implemented in Haxe or not?

I looked into implementing this briefly and I think it can be supported, but requires some thought, so I'll make a Haxe Evolution proposal describing how it should work and we'll discuss it a bit.

[nadako]

I am unassigning myself from this due to lack of interest. See #9433 and https://github.com/HaxeFoundation/haxe-evolution/pull/32 for two possible solutions for this if anyone wants to push this forward.

[nadako]

We need this at @innogames for a structure like this (note the function field).

typedef StackTraceFrame = {
    abs_path:String,
    lineno:Int,
    in_app:Bool,
    module:String,
    filename:String,
    function:String
}

This structures goes throgugh Json.stringify to the third-party service, so it's not particularly easy to use a different name. Of course there are multiple workarounds of different level of messiness, but having a proper builtin solution would be much preferred, I'll add a hf-partner label to this issue, because I believe it's best for everyone if this situation is addressed sooner.

[RealyUniqueName]

I agree we need a solution. I think the proposed one is ok to implement as it will be consistent with the current approach to class fields, and would allow further improvements to be made later (like obj."field" or whatever)

[haxiomic]

I've created a macro workaround if anyone is needing a solution before compiler changes: AbstractAnon.hx

It converts a anon structure into an abstract with getters and setters to access the @:native fields

[danielo515]

So is this in the works? What is the status? This will greatly reduce my frustration with the Lua target