• Create Account

### #ActualAndreas Jonsson

Posted 30 August 2012 - 01:09 PM

I believe it ought to be pretty straight forward now. It should only require a few changes to the asCCompiler class. There are basically two places that needs to be updated, CompileFunctionCall() and CompileExpressionPostOp().

The first is for when the expression looks like an ordinary function call, i.e.

Object obj;
obj();			 // <-- CompileFunctionCall() needs to look for an opCall method in the Object class


The second is for when the expression preceeding the argument list isn't a simple symbol, but in itself another expression that returns an object that implements an opCall method, e.g.

array<Object> arr;
arr[0]();	  // <-- CompileExpressionPostOp() needs to look for an opCall method in the Object class


The easiest way to determine what to change is by debugging the compiler while compiling a script you want to work.

While I'm not a big fan of call operators myself, I can still incorporate them into the language as they don't cause any negative impacts.

### #1Andreas Jonsson

Posted 30 August 2012 - 01:07 PM

I believe it ought to be pretty straight forward now. It should only require a few changes to the asCCompiler class. There are basically two places that needs to be updated, CompileFunctionCall() and CompileExpressionPostOp().

The first is for when the expression looks like an ordinary function call, i.e.

Object obj;
obj();             // <-- CompileFunctionCall() needs to look for an opCall method in the Object class


The second is for when the expression preceeding the argument list isn't a simple symbol, but in itself another expression that returns an object that implements an opCall method, e.g.

array<Object> arr;
arr[0]();      // <-- CompileExpressionPostOp() needs to look for an opCall method in the Object class


The easiest way to determine what to change is by debugging the compiler while compiling a script you want to work.

PARTNERS