(new) Syntax for function pointers?

Since there is lack of feedback in the IRC channel.

function pointers are awesome, specially when you compare them to the lame boolexpr and code stuff, enforces you to manually use triggers and keep cleaning their conditions, and to manually return true, etc. Plus function pointers perform better and also may have arguments and return values.

For what I know, everybody using vJass syntax should use function pointers instead of boolexprs/etc for this reason, why doesn't this happen? I'd say it is because the syntax is rather complicated to use in comparison to function FunctionName.

This is an example:


The part that I think is the one that sets people apart is the way to instanciate a function pointer, asking for "FunctionInterfaceName.functionName" is just too much in comparison to "function functionName", the rest is complicated but there is no other way to tell vJass what the heck you want to do, also, all that stuff of declaring an interface is supposed to be used by the guy making the system. Instantiating the function pointer is what users should do... FunctionInterfaceName.functionName is also a little unintuitive.

So, I just found out there are ways to fix this, and not require you to specify the functioninterface name. The old syntax should remain as it is useful to allow validation but this:


call myDostuff( myFunction.code )
is possible. All what is left is to decide a keyword, I unfortunately cannot use function myFunction at least not too soon . But these are possible alternatives:

I do agree that function interfaces are awesome and should be used more.

I'm more in favour of a keyword in front of the function name, because that's similar to how code variables already work, while a keyword attached at the end with "." seems confusing since "." is typicaly used in struct syntax.

The tricky part is coming up with a good keyword, I suggested pointer myFunction but that wasn't accepted for obvious reasons (though, you used the term a couple of times in this thread).vfunction is ok I guess except that people who aren't entirely familiar with it might think it's a typo. Method is already taken, how about procedure myFunction (yes, I am just taking synonims off of Wikipedia).

procedure can't work because the function is likely to have a return value...

coroutine then, or is that too obscure?

you will have to kill me before I use sub.

function& myFunc

Is that remotely feasible?

Well, it would be nice if the keyword was an actual word, but if vfunction is ok, how about fpointer or funcpointer?

I'd say the & is too uncommon in jass, so maybe something that suits the language better? I'd suggest using vfunction myFunc since it differs from the normal function myFunc, but also looks very similar, and the little "v" invariably shows where that keyword comes from. Also I think, since it has almost the same purpose as function myFunc it should also look almost the same(which vfunction does).

Edit: @Anitarf's suggestions: I don't think we should use something shortened here - like fpointer or funcpointer, since jass isn't a language with many abbreviations(imo)

I can't remember the dot operator being used at all before vJass, and who would say it is unsuited to the language now? Stuff like vfunction, funcpointer, ptrfunction is ugly, like 2 different things have been crudely mashed together. The function keyword retains more of its identity in function&, and the use of the & will be familiar to many, so that would be my first choice if it is feasible to implement it.

well, that is true, the dot operator wasn't used before, but I think the dot operator is much more common in vJass now than the &-operator(or any other operator we choose for this syntax) will ever be, also the dot operator introduced a whole new element to the language, while the function pointers already existed before(in form of the "code" parameter), and are now *only* being extended... Somehow I don't like how the & is mixing up with the function keyword...

How is vfunction not an abbreviation?

TheDamien: In that case, why &, why not function.MyFunc or function:MyFunc or whatever?

gah.. I was in a hurry when writing that, so I totally missed the obvious ... still, vfunction sounds more familiar to the normal function keyword than any other suggestion so far, and that is the reason I'd prefer it.

Edit: btw, how about call-syntax for function pointers? so we don't need the .evaluate/.execute-syntax anymore, we just have one of them as default(e.g. .evaluate as default, ppl could still use .execute), and let those pointers use the call-keyword, like normal functions? But I guess that isn't possible(as of yet), since it would most probably already be implemented if it was.

what about func_ptr or function_ptr?

Everything already existed before. It is easier to emulate structs in the way they are most frequently used today than it is to emulate function pointers and provide them with arguments and return values. I would probably be using function pointers way more than structs if it weren't for the current syntax.

Anyway, & isn't meant to be some radical addition to the syntax to be used more, or as much as, the dot operator. It just fulfills its purpose and nothing more.


If & is unsuited to the language, then <Type>.<Name> as a form for arguments is even less suited. Not only that, but it doesn't make sense. The syntax makes it look like MyFunc is a property of some weird function object, or that there is a function called MyFunc.

My ideal syntax for function pointers (since sub is out of the question):