It's the pedant in me triggered by my programming background where functions have returned values and procedures or subroutines do not. In C/C++/C#, that would be the difference between void and non-void return values. In VB, that would be the difference between SUB and FUNCTION. I'm also thinking of how the FUNCTION command in TCC is used. In the example above, test doesn't actually
return a string. Instead, the subroutine is setting a value that can later be checked. If the above were an actual function, doing
echo %@test[] would be valid and not produce an error.
I often use the
@echo combined with
@execstr to have some of my aliases reusable as functions. My function file would have these defined as
func=%@execstr[alias %1] so I could directly use the result of calling the alias within an expression or comparison. But, this doesn't make the original alias itself a function. With a FUNCTION defined function, you can
echo %@func[] or
if %@func[] GT 0 to directly get/use the returned value. With a LIBRARY defined function, you cannot use the resultant (singular?) value directly. You would need to wrap it in an actual function to retrieve that 'return' value before it could be used. Thus, doing
echo %@libfunc[] would fail while doing
echo %@execstr[libfunc] would work. But, as I said at the opening of this post, this is just pedantry on my part.
Along this semantic/pedantic vein, this gives me the idea of method, where the function, procedure, or subroutine is internal to a class or, in this case, the file. That may lead to defining library methods as
That would then allow for the prefix usage of
LIBRARY /D library.* to remove all methods defined in that file. This then has me thinking of combining array variables with library files to simulate C++ style classes in BTM language. In addition to containing the class member variables, the array could also contain the vtable of the related internal methods. But, this gets into a whole other topic.
