create new abstract inside its method

[ktimothy]

Look at that code, especially the set method in DynamicArrayAccess

// need an array access on anonymous objects
abstract DynamicArrayAccess<T>(Dynamic<T>) from Dynamic<T>
{
    public inline function new(d:Dynamic<T>) this = d;

    @:arrayAccess
    public function set(key:String, value:T):Void
    {
        // Reflect.setProperty was the first decision
        // but I wanted to do it without Reflect
        // and I suddenly remembered, that my abstract is perfect for that
        new DynamicArrayAccess(this)[key] = value;
    }

    @:arrayAccess
    public inline function get(key:String):T
    {
        return Reflect.getProperty(this, key);
    }
}

class Test {
    static function main() {
        trace("Haxe is great!");

        var a:Dynamic<Int> = {};

        var a:DynamicArrayAccess<Int> = { k: 10 };
        a["k"] = 20;

        trace(a["k"]); // 20
    }
}

The generated in js setter look like

_Test.DynamicArrayAccess_Impl_.set = function(this1,key,value) {
    this1[key] = value;
};

How could that successfully compile? =)

[nadako]

While I acknowledge the weirdness of the generated _set method (@Simn shouldn't it generate a recrusive call there?), I don't understand why are you trying to write it that way. You're working with Dynamic so Reflect.field/setField/deleteField is the way to go. Also, using Reflect.getProperty is most probably the unnecessary overhead compared to Reflect.field if you intend to use that abstract with anonymous structures.

We've recently added haxe.DynamicAccess which is probably what you want to achieve anyways: https://github.com/HaxeFoundation/haxe/blob/development/std/haxe/DynamicAccess.hx

[ktimothy]

Well, I simply did some experiments, that code will never get to production. Just noticed the strange behavior.

Thanx, DynamicAccess should be useful, but

1. it has no @:forward, so I cannot use dot field access
2. I have a bug with casting anonymous object to DynamicAccess

[Simn]

This probably happens because the set field has no expression at the time of typing itself (obviously), so the recursive call generates a normal TArray node.

We have to distinguish this case from cases where the field really has no expression in the first place. Getting this right might require some work because there could be a mutual relationship between several fields which leads to one of them not having any expression at the time of typing. I prefer to not address this at the moment.

[Simn]

Thinking about it again we should address this right away because the earlier we break it the better.

[Simn]

This is not properly disallowed.