-
-
Notifications
You must be signed in to change notification settings - Fork 662
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Haxe's Generated Neko Source Unable to Utilize Inlined Getter Methods on Dynamic Objects #7368
Comments
Unfortunately, this is necessary because neko has an evaluation order that doesn't match Haxe's when it comes to calls. See #4787 (comment) |
@Simn There is something I don't understand about my issue in relation to that thread. How could the evaluation order differ between any of Haxe's supported platforms in my code? (JS, HXCPP, etc.). Unlike that other thread I am not writing things like I'm ok with avoiding If modifying Haxe's output is too risky then I understand. But I strongly feel that this should be surfaced during compilation time as a warning if nothing else. This could be caught when an unknown type gets assigned to a temp, or any |
Maybe I misunderstood your example. Can you reduce it to something that doesn't involve OpenFL? |
Sure, I've pushed a new branch that just uses raw Haxe code: https://github.com/Cleod9/WeirdOpenFLNekoBug/tree/without-openfl The problem remains the same, where a function call gets assigned to a temp variable when it was unnecessary since there are no evaluation order gotchas. |
I took another look and what I originally said is correct after all. You have this code in ObjOuterWrapper.hx: inner_wrapper.a(value.get_instance()); With neko's evaluation order being backwards, it evaluates |
Hi @Simn , thanks for taking the time to investigate further. Just to clarify for my piece of mind-
var a = function () {
console.log("inside a");
}
var b = function () {
console.log("inside b");
}
a(b()) Prints
The JS version of my example keeps the code inlined while Neko does not. If the JS evaluation order in this case is the same as Neko and Neko is known to be "backwards", wouldn't that mean one of the two outputs by Haxe is inconsistent? |
That is not the correct example, you will need something like As for a flag, we don't want any global flags that influence semantics like that. You can easily solve this locally through one of the workarounds you came across. And in general, try avoiding |
Alright got it, I'll leave it at that 👌 |
Minimal Test Case:
https://github.com/Cleod9/WeirdOpenFLNekoBug
Original source thread here:
http://community.openfl.org/t/strange-neko-bug-when-inlining-getters/10888/6
All details from the original thread have been added to the repo's readme, but the gist of it is as follows:
A simple inline expression such as
obj1.func(obj2.get_my())
will fail ifobj1
is dynamic because Haxe's Neko output expands the expression by assigningget_my
into a temporary variable. This results inget_my
becoming an anonymous function, which will have lost its context.My recommendations are to do one of the following:
Dynamic
vars that can be assumed to be functions (e.g.$call(tmp, this.stage,$array(this.stage));
)However if none of the above is possible, I think a build warning would be extremely helpful for others who run into this.
The text was updated successfully, but these errors were encountered: