open.mp forum
[Pawn] y_hooks v4(ish) - Printable Version

+ open.mp forum (https://forum.open.mp)
-- Forum: SA-MP (https://forum.open.mp/forumdisplay.php?fid=3)
--- Forum: Pawn Scripting (https://forum.open.mp/forumdisplay.php?fid=10)
--- Thread: [Pawn] y_hooks v4(ish) (/showthread.php?tid=569)

y_hooks v4(ish) - Y_Less - 2019-05-19

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.

RE: y_hooks v4(ish) - JustMichael - 2019-05-21

I'm a fan of both 2,3 and 4. Since they don't over complicate anything and looking at the rest it doesn't look like newbies will comprehend that and will most likely push them away.



I don't mind `continue` or `next` as keywords to move to the next hook maybe even `next` and `cancel` or `continue` and `break` (depends if you want to mix in with the current keywords)

Though thinking about it `continue` and `break` are keywords that exist in many languages, and I don't know how I feel about re-using them for a different cause, it might confuse people.



`next` and `cancel` seem like good alternatives, if you have no objections to them. They are easy to comprehend and they are not used elsewhere.



I'm not a big fan of putting `hook` in front of every keyword that doesn't feel right to me at all.

RE: y_hooks v4(ish) - Y_Less - 2019-05-21

(2019-05-21, 11:57 AM)JustMichael Wrote: I'm a fan of both 2,3 and 4. Since they don't over complicate anything and looking at the rest it doesn't look like newbies will comprehend that and will most likely push them away.



Good.



(2019-05-21, 11:57 AM)JustMichael Wrote: I don't mind `continue` or `next` as keywords to move to the next hook maybe even `next` and `cancel` or `continue` and `break` (depends if you want to mix in with the current keywords)

Though thinking about it `continue` and `break` are keywords that exist in many languages, and I don't know how I feel about re-using them for a different cause, it might confuse people.



`next` and `cancel` seem like good alternatives, if you have no objections to them. They are easy to comprehend and they are not used elsewhere.



The major problem with new keywords is compatibility - making sure they don't break existing code which ma already use them as function or variable names.



(2019-05-21, 11:57 AM)JustMichael Wrote: I'm not a big fan of putting `hook` in front of every keyword that doesn't feel right to me at all.



Do you mean you don't like the `hook public` and `hook native` syntax as well? There isn't really another way to do that.

RE: y_hooks v4(ish) - JustMichael - 2019-05-21

(2019-05-21, 12:56 PM)Y_Less Wrote:
(2019-05-21, 11:57 AM)JustMichael Wrote: I'm a fan of both 2,3 and 4. Since they don't over complicate anything and looking at the rest it doesn't look like newbies will comprehend that and will most likely push them away.



Good.



(2019-05-21, 11:57 AM)JustMichael Wrote: I don't mind `continue` or `next` as keywords to move to the next hook maybe even `next` and `cancel` or `continue` and `break` (depends if you want to mix in with the current keywords)

Though thinking about it `continue` and `break` are keywords that exist in many languages, and I don't know how I feel about re-using them for a different cause, it might confuse people.



`next` and `cancel` seem like good alternatives, if you have no objections to them. They are easy to comprehend and they are not used elsewhere.



The major problem with new keywords is compatibility - making sure they don't break existing code which ma already use them as function or variable names.



(2019-05-21, 11:57 AM)JustMichael Wrote: I'm not a big fan of putting `hook` in front of every keyword that doesn't feel right to me at all.



Do you mean you don't like the `hook public` and `hook native` syntax as well? ?There isn't really another way to do that.



I am okay with `hook public` and `hook native` but not okay with `return hook continue(a 5);` or something like that. It might just be me being used to the previous way.

RE: y_hooks v4(ish) - ohmios - 2019-05-21

(2019-05-21, 12:56 PM)Y_Less Wrote: The major problem with new keywords is compatibility - making sure they don't break existing code which ma already use them as function or variable names.



Do what C does with new keywords, the actual new keyword for "foo"?is?_Foo, and to use "foo" as "foo" you have to include foo.h

That said, code using "continue" or "break"?as function or variable names?deserve to be broken.

RE: y_hooks v4(ish) - Y_Less - 2019-05-21

(2019-05-21, 02:02 PM)ohmios Wrote:
(2019-05-21, 12:56 PM)Y_Less Wrote: The major problem with new keywords is compatibility - making sure they don't break existing code which ma already use them as function or variable names.



Do what C does with new keywords, the actual new keyword for "foo"?is?_Foo, and to use "foo" as "foo" you have to include foo.h

That said, code using "continue" or "break"?as function or variable names?deserve to be broken.



Well `continue` and `break` are already keywords, so I'm not worried about them, I was more talking about if I were to add a new keyword like `next`.



And I do already do something similar in YSI. `hook` is actually defined as `HOOK__`, and there are various options to enable or disable the custom `hook` keyword (but enabled by default):



https://github.com/pawn-lang/YSI-Includes/blob/5.x/YSI_COMPATIBILTY_MODE.md

RE: y_hooks v4(ish) - Kar - 2019-05-21

wtf

RE: y_hooks v4(ish) - Y_Less - 2019-06-01

Just got this working:



PHP Code:
HOOK_NATIVE__ printf(const str[], GLOBAL_TAG_TYPES:...)

{

    printf("a__ = %d", a__);

    printf("f__ = %d", f__);

    printf("(%s, %d...)", str, numargs() - 3);

    // Need to make this nicer - it won't currently work if any other parameter

    // has an underscore in.  This secretly adjusts the number given to ` 2` to

    // account for the two extra parameters.

    return continue(str, ___(1));

} 



There's still a little way to go automatically detecting and installing the hooks, but the hard part is done.

RE: y_hooks v4(ish) - Y_Less - 2019-06-01

I had an idea, and significantly improved it:



PHP Code:
HOOK_NATIVE__ printf(const str[], GLOBAL_TAG_TYPES:...)

{

    printf("(%s, %d...)", str, numargs() - 1);

    return continue(str, ___(1));

} 



Yes, it looks the same, but I've fixed all the problems with parameter numbers, and also fixed the limitation that `continue()` could only be called from directly inside the hook. Now it can be called from any child function as well, without the problems I initially envisioned with types and recursion.

RE: y_hooks v4(ish) - JustMichael - 2019-06-01

Really starting to love this new design for it. I am looking forward to seeing it in action ;)



This looks super interesting to me.

Code:
return continue(str, __(1));


RE: y_hooks v4(ish) - Y_Less - 2019-06-02

(2019-06-01, 03:37 PM)JustMichael Wrote: Really starting to love this new design for it. I am looking forward to seeing it in action ;)



This looks super interesting to me.

Code:
return continue(str, __(1));



Well that's just combining it with y_va.