what is the best practice of fixing up module functions with more than two params?
in mod_fix.h there is some three param fixups defined, but not all possible param type combinations. also, adding four param fixups will not scale, since the number or possible type combinations would be too large.
-- juha
Hello,
On 4/7/10 7:38 AM, Juha Heinanen wrote:
what is the best practice of fixing up module functions with more than two params?
in mod_fix.h there is some three param fixups defined, but not all possible param type combinations. also, adding four param fixups will not scale, since the number or possible type combinations would be too large.
mod_fix.h should be used if there are more than one module using that fixup, otherwise makes no sense, the fixup should stay in the module.
Using type of parameter in name of function does not scale anymore, so a different name pattern should be chosen. Can be developer choice, preferably suggestive if possible.
Cheers, Daniel
Daniel-Constantin Mierla writes:
mod_fix.h should be used if there are more than one module using that fixup, otherwise makes no sense, the fixup should stay in the module.
Using type of parameter in name of function does not scale anymore, so a different name pattern should be chosen. Can be developer choice, preferably suggestive if possible.
how about a new scheme, where in exports module writer lists the fixups in an arg string, for example,
{"test", (cmd_function)test, "pvar,str,spve", REQUEST_ROUTE | FAILURE_ROUTE},
names in the arg string can be well known (in which case nothing else needs to be done by module writer) or custom (in which case the corresponding fixup needs to be written by module writer).
-- juha
On Apr 07, 2010 at 20:10, Juha Heinanen jh@tutpro.com wrote:
Daniel-Constantin Mierla writes:
mod_fix.h should be used if there are more than one module using that fixup, otherwise makes no sense, the fixup should stay in the module.
Using type of parameter in name of function does not scale anymore, so a different name pattern should be chosen. Can be developer choice, preferably suggestive if possible.
how about a new scheme, where in exports module writer lists the fixups in an arg string, for example,
{"test", (cmd_function)test, "pvar,str,spve", REQUEST_ROUTE | FAILURE_ROUTE},
names in the arg string can be well known (in which case nothing else needs to be done by module writer) or custom (in which case the corresponding fixup needs to be written by module writer).
In master it will soon be possible to have variables automatically supported for functions with no fixups. However the args must not be in quotes (no automatic fixup takes place for quoted strings). E.g. foo($a, "test " + $b + "\n") will work (the code is already in the andrei/rve_f_params branch).
Andrei
Andrei Pelinescu-Onciul writes:
In master it will soon be possible to have variables automatically supported for functions with no fixups. However the args must not be in quotes (no automatic fixup takes place for quoted strings). E.g. foo($a, "test " + $b + "\n") will work (the code is already in the andrei/rve_f_params branch).
that is great news. i'll give it a try when in master branch, for example, for cleaning up enum functions.
-- juha
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
jh＠tutpro.com