[Pawn] y_hooks v4(ish)

[Y_Less]

Right, so I've been thinking about y_hooks.

This is the current syntax:

PHP Code:

hook OnWhatever()
{
} 


Chaining is implicit - the only control you get is returning `~0` instead `0` to stop the next hook being called. ?Only `0` or `1` can be returned; and only public functions can be hooked.

A while ago I came up with an extension:

PHP Code:

hook public OnWhatever()
{
}

hook stock MyFunc()
{
}

hook native SendCommand()
{
} 


I don't like using `stock` in this context, as it reinforces the idea that so-called "stocks" are functions, and vice-versa, but any more accurate keyword would mean introducing additional new ones, which I don't want to do. ?Using the old `hook` syntax would continue to work in exactly the way it does now. ?For the new syntax, I may as well fix all the issues at once - return values as well. ?This means adding an explicit method of chaining:

PHP Code:

hook public OnPlayerConnect(playerid)
{
    if (0 <= playerid < MAX_PLAYERS)
    {
        return CallNextHook("OnPlayerConnect", "i", playerid);
    }
    return 0;
}

hook native random(max)
{
    if (max < 0)
    {
        return -CallNextHook("random", "i", -max);
    }
    if (max > 0)
    {
        return CallNextHook("random", "i", max);
    }
    return cellmin;
} 


I'd like some slightly nicer syntax for the chain call, and this is where I'm looking for feedback. ?There are several options:

1. Exactly what's above, just an obvious function call. ?This has several downsides - verbose, variable parameters, string argument specifier (error-prone), string function name; and only one upside - not custom syntax.
   
   
2. Using indirection.inc with the hook name:
   
   
   PHP Code:

   return @.OnPlayerConnect(playerid); 

   
   Advantages: Established syntax, compile-time specifier determination (can be part of the `hook whatever` line, don't worry about that), less verbose, more clear.
   
   Disadvantages: Still no compile-time parameter checking, but none of the proposals have that.
   
   
3. Using indirection.inc with the `hook` keyword:
   
   
   PHP Code:

   return @.hook(playerid); 

   
   Basically the same as option "2", but more consistent across all hooks, and less likely to conflict with other variables. ?As for specifiers, there are two options - 1) none, which is not good, but means that the chaining is no longer tied to the hook function:
   
   
   PHP Code:

   Other(a)
{
    return @.hook(a);
}

hook stock MyFunc(a)
{
    return Other(a);
} 

   
   Or the other option is just make `hook` a local in exactly the same way as would be done in option "2a".
   
   
4. `continue`.
   
   I like this for one reason - it is quite clear on meaning:
   
   
   PHP Code:

   hook stock MyFunc(a)
{
    new b = continue(a  5);
    return b - 5;
} 

   
   `continue()` cannot conflict with `continue`, so this is a completely unambiguous overload of an existing keyword.
   
   
5. `hook continue`.
   
   Like "4", but using slightly more verbose, less confusing, syntax:
   
   
   PHP Code:

   hook stock MyFunc(a)
{
    new b = hook continue(a  5);
    return b - 5;
} 

   
   
6. `yield continue`.
   
   Again, like "4" and "5", but reusing the `yield` keyword, already existant in YSI. ?`y_iterate` uses `yield return`, so this would provide meaning to `yield continue` as well:
   
   
   PHP Code:

   hook stock MyFunc(a)
{
    new b = yield continue(a  5);
    return b - 5;
} 

   
   
7. Completely custom syntax:
   
   
   PHP Code:

   hook stock MyFunc(a)
{
    // Example custom syntax, probably not this, maybe `next()`.
    new b = next_hook::MyFunc<>!!!(a  5);
    return b - 5;
} 

   
   
8. Something I've not thought of.
   

My personal preference is actually for `continue()`. ?It is quite clear, unambiguous in usage (the normal use can't have brackets), and actually allows for slightly better code than that which would be run by using any of the indirection.inc options. ?However, they have the advantage of established practice. ?So my choices in order of preference would be: 4, 3, 5/6, 2, 1, 7. ?Unless, of course, someone has a better option 8.

Explicit chaining implicitly solves the return values problem - any value can be returned, and you don't need `~0` and `~1` reserved for chaining control because you now say exactly when the next function is called. ?You can also use the return of the next chained call.