haxetink / tink_anon Goto Github PK

@nadako dropped this gist in the haxe gitter some time ago: https://gist.github.com/nadako/7edbc859e5206b2dbd65df2fd96aa334
Seems like it could be a good fit to add something like this to tink_anon?

db.Foo.select({ foo: Foo.foo }).next( o -> tink.Anon.merge( o, ref = transform(o.ref))); fails compilation with:

expected type should be struct or @:structInit.

These variants work though:

• .next( o -> { var r = tink.Anon.merge( o, ref = transform(o.ref)) ); r; }
• .next( o -> Success(tink.Anon.merge( o, ref = transform(o.ref))) )
• .next( o -> o = tink.Anon.merge( o, ref = transform(o.ref)) )

I'm going to use the last one for the time being.

This does not work:

var a = {v: "none"};

function getResult(isYes:Bool)
	return tink.Anon.merge(a, isYes ? {v:"it works"} : {});

trace(getResult(true));
trace(getResult(false));

OTOH this works:

tink.Anon.merge(a, {v: isYes ? "it works" : ""});

I believe it is not trivial thing to fix (if even possible) so adding a compilation error and a notion to readme about this kinds of limitation would be useful.

var o = EitherType<{i:1}, Array<{i:1}>> = merge(i = 1);

Could the macro be clever enough to figure out what to produce? If it can rule out impossible outputs (Array in this case) then it should be easy. Otherwise if the two types are both structures it might have to "try"...

@back2dos

Ensuring the same runtime structure for anonymous objects of the same compile time structure generally makes life easier for JITs.

It also has a couple of adverse effects though, so it should be customizable.

See title. Consider supporting @:privateAccess as well.