onInit() op limit surpass

[GoogleCodeExporter]

The way onInit() is currently compiled, it can easily exceed op limit.
Instead of calling onInit functions, use ExecuteFunc() since it creates a new 
thread.

Proof:
library lib {
    callback onInit() {
        for(integer i=0;i<500;i++) {BJDebugMsg("lol")}
        BJDebugMsg("end") //This debug message gets displayed which means the op limit isn't exceeded for 500 debug calls
    }
}

library lib {
    nothing lol() {
        for(integer i=0;i<500;i++) {BJDebugMsg("lol")}
    }

    nothing lol2() {
        for(integer i=0;i<500;i++) {BJDebugMsg("lol")}
    }

    callback onInit() {
        lol()
        lol2()
        BJDebugMsg("end") //Doesn't get displayed since the op limited is exceeded
    }
}

library lib {
    nothing lol() {
        for(integer i=0;i<500;i++) {BJDebugMsg("lol")}
    }

    nothing lol2() {
        for(integer i=0;i<500;i++) {BJDebugMsg("lol")}
    }

    callback onInit() {
        ExecuteFunc("lol")
        ExecuteFunc("lol2")
        BJDebugMsg("end") //Gets displayed since ExecuteFunc creates a new thread
    }

Original issue reported on code.google.com by vladimir...@gmail.com on 1 Sep 2011 at 12:04

[GoogleCodeExporter]

Maybe you're right. But in vJass libraries initialized by ExecuteFunc, but 
scopes by call - why?

Also onInit callback designed as easy init and not as replacing of libraries, 
scopes or structs initializator.

Original comment by adi...@gmail.com on 1 Sep 2011 at 5:02

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Oh. But why shouldn't it replace the ones from libraries and other? It's much 
easier to just type callback onInit() {} then to type initializer blabla and 
make the function.
You could also make it that onInit callbacks in structs and modules are 
compiled to struct/module onInit. Although for module it should be compiled to 
a private onInit() so it counts as it's own onInit.

Original comment by vladimir...@gmail.com on 1 Sep 2011 at 5:16

[GoogleCodeExporter]

Instead of ExecuteFunc Troll-Brain suggested to me (before I abandoned the 
LuckyParser project), to use "ForForce(bj_FORCE_PLAYER[0], function 
name__onInit)" instead of ExecuteFunc("name__onInit"). The reason why is 1) 
less string leaks and 2) it's going to be a lot faster initialization.

Sure the disclaimer should read "don't use with TSA", but if you'd rather have 
integration instead of a disclaimer, and have the time, you could check if that 
onInit in some way calls a TSA, and if so it should use an ExecuteFunc.

Original comment by lukecke...@gmail.com on 4 Oct 2011 at 4:28