OK, this bug is more serious than expected. Here's the problem: ZScripts are a compile-time fiction. For example, consider the following scripts:
ffc script a {
voir run() {a();}
void a() {...}
void b() {...}
}ffc script b {
void run() {a.a(); a.b();}
void c() {...}
}
When this source is compiled, two ASM "chunks" are created: a's run script, together with the code from a.a(), and b's run script, with a second copy of a.a() and a.b(). b.c() is completely ignored and missing entirely from the output. Basically, the compiler determines what methods are called by what scripts, and slaps on those methods accordingly.
So for the bug at hand, the problem is that it's not clear what "this" should point to when you call a non-run method. There are three options:
1. Helper methods cannot use the this pointer. It must be passed in explicitly, as in my above post.
2. The this pointer is passed implicitly. There are two dangers to this approach. First, it's easy to get confused about what the this pointer points to. For instance,
ffc script a {
void run() {}
void helper() {this->X = 100;}
}ffc script b {
void run() {a.helper();}
}
When b's script is run, it is the ffc associated with b, not a, that is moved.
Second, calling a method of a different type of script is disastrous if that method uses the this pointer. For instance, the following snippet
item script a {
void run() {}
void helper() {this->X = 100;}
}ffc script b {
void run() {a.helper();}
}
will experience undefined behavior and probably crash.
For these reasons I'm leaning towards option 1, although I am also open to
3. Something completely different.
Thoughts?