The discussion for proxy implementation was already conducted over IRC with Pim and sby.
We considered a number of different ways to allow the user to replace methods and repeatedly ran in to conflicts in terms of:
Proxy as stack or queue.
Passing forward arguments on return.
How to correctly handle return values when dealing with vanilla.
Your idea for a stack based queue only makes sense when considering the ability to pass forward arguments.
However since passing arguments forward doesn't make sense, I don't think it's useful to implement either, let me explain:
hugo_boss said:
Iwas thinking about something like a second type of pre function, that returns an array,, wich will be forwarded as input parameters to the next function, similar to how the post functions work.
pre2(param1a, param1b); --> returns param2a and 2b
pre 1(param2a, param2b) --> returns param param3a and 3b
original (param3a, param3b) --> returns ret1
Pre functions were designed to do two things:
Listen for function execution.
Potentially modify return values for vanilla.
They were never designed to cascade because return values from one would not cleanly pass to another without special consideration.
Passing arguments forward is not a good idea. Preferably, you'd do the following:
Proxy some function.
Add pre, unhook.
Parse arguments, perform function and call original with new arguments.
Now of course this doesn't work with already proxied methods, and they shouldn't.
The reason why is because these mods have an established expectation of what kinds of values they should be receiving, being able to modify the input of these methods essentially means applying proxies to proxies and should never be a good idea.
If you're ever in a position where you NEED to do this, contact the mod author and discuss with them how better to implement their logic.