- Wed Nov 16, 2016 11:09 am
#58212
All Function calls have the common ability to pass and return data with each function call, if needed.
So a TRIM(var or string) function could for instance take the raw data and return the trimmed result.
TRIM() doesn't exist in Esp_Basic, and to create a functional equivalent would require copying the required string into a global 'transfer' variable, gosub to a [TRIM] subroutine which must be written to use the specified transfer variable, then after 'return'ing from the subroutine, copy the modified global transfer variable to wherever it is needed or originally belonged... and that might need doing dozens of times.
How much more elegent and convenient it might be if some sort of...
USER_FUNCTION( [branch], {string or var1}, {string or var2}, {string or var3})
was available. The specified subroutine branch could extract the appropriate data from any supplied strings or variables, perhaps using a passed var or string to modify behaviour if required, then return the modified 'result' string or variable.
It would allow users to pass data to and from their own user-defined functions to effectively create their own functions from subroutine procedures which otherwise could not exchange data with the running program.
I'm not a professional programmer, so perhaps I'm talking rubbish, but I think it should be feasible for a USER_FUNCTION to 'goto' the supplied subroutine [BRANCH], where the subroute can manipulate the specified vars data, putting the results into (eg:) a RESULTS var, then the subroutine RETURN command returns back to the calling USER_FUNCTION which returns whatever is in the RESULTS var, so even allowing the returned function results to be used in comparison tests if needed.
It would open up the possibility for users to easily create any FUNCTIONality whenever they need.
So a TRIM(var or string) function could for instance take the raw data and return the trimmed result.
TRIM() doesn't exist in Esp_Basic, and to create a functional equivalent would require copying the required string into a global 'transfer' variable, gosub to a [TRIM] subroutine which must be written to use the specified transfer variable, then after 'return'ing from the subroutine, copy the modified global transfer variable to wherever it is needed or originally belonged... and that might need doing dozens of times.
How much more elegent and convenient it might be if some sort of...
USER_FUNCTION( [branch], {string or var1}, {string or var2}, {string or var3})
was available. The specified subroutine branch could extract the appropriate data from any supplied strings or variables, perhaps using a passed var or string to modify behaviour if required, then return the modified 'result' string or variable.
It would allow users to pass data to and from their own user-defined functions to effectively create their own functions from subroutine procedures which otherwise could not exchange data with the running program.
I'm not a professional programmer, so perhaps I'm talking rubbish, but I think it should be feasible for a USER_FUNCTION to 'goto' the supplied subroutine [BRANCH], where the subroute can manipulate the specified vars data, putting the results into (eg:) a RESULTS var, then the subroutine RETURN command returns back to the calling USER_FUNCTION which returns whatever is in the RESULTS var, so even allowing the returned function results to be used in comparison tests if needed.
It would open up the possibility for users to easily create any FUNCTIONality whenever they need.
