I'm curious about future prospects on a function call operator in Angelscript. Messy though they can be, operator() overloads are super-useful and something I use frequently in C++ to avoid wordy APIs. It also allows for functors and the like.
As an example, I have a module called "Random" in my game engine, exposed to Angelscript as a global, which can generally be treated like an overloaded function to generate random numbers with various parameters. Additional Random objects can also be created for deterministic simulations and the like, so I'd be losing some functionality if I just exposed this stuff as global functions.
class Random
{
public:
Uint32 operator()(Uint32 max);
Uint32 operator()(Uint32 min, Uint32 max);
I currently do not have any plans on adding support for function call operators in the script language. Though I won't go so far as saying that it will never be done, I just don't feel they add enough value to make it worth it at the moment.
That doesn't mean you can't register your Random class with AngelScript though. You just have to give a name for your nameless functions when registering them, example:
For my part, it's a feature I'd really like to see, but I've also written a parser or two and know it would be a giant pain in the butt to implement. So I understand if it's late or never. To be honest I'd take property accessors over function-call operators any day of the week.
Oh, no, I'm quite aware. I'm saying I'm happy to have property accessors. But anyway. Keeping my fingers crossed. And who knows? Maybe if I'm antsy enough it's the sort of thing I could write a preprocessor for.
Pardon the necro-post; the release of version 2.24 makes this relevant again.
A statement from Andreas in my topic on hardcoding geometry and initializer lists:
TheAtom reported a bug today about making calls with function defs. I still need to investigate what changes needs to be made to support those scenarios, but as they look similar in syntax to what the use of a function call operator might look like I recommend you wait a little until I've fixed that bug before you dig too deep into the code.[/quote]
Since the improved semantics for function pointers are now implemented, how straightforward would the implementation of an opCall be? (Either as a new official addition to the language or, barring that, as a hack to my own copy?)
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.
Are there any particular caveats responsible for this remark in CompileFunctionCall? (Version 2.24.1)
// TODO: funcdef: It is still possible that there is a global variable of a function type
Or would it be safe to add the variable-access resolution code?
