Originally Posted By: RRX
If you want to write a script in such a way that another scripter (so some1 that knows what he does) can easily add his own code sections/modules for it, then this gosub method would come in as a method that allows to keep the code parts separated, so no mix of one scripter's code with another's code.

But let's consider the namespace. It was said that the locals of the calling place should be preserved. Ok, but that means that the 'sub'routine cannot alter them. This is rather contradictional with the idea of being able to 'construct' a script from code on different locations/different scripters.

I stated that locals would be 'preserved' from the caller, become available to the caller when the sub returns. That would mean alterations would be passed back to the caller.

My problem is that I tend to keep my code modularized, and I avoid global variables due to potential name collision, but it's otherwise impossible to pass two space-containing strings to an alias without using some token separator or calling the alias as an $identifier. It's also dreadfully slow to constantly pass several large strings back and forth from alias to alias.

Currently, I've been using binary variables as cross-alias storage containers, but they too are extremely inconvenient.

Anyway. Here's a small example where sub routines would come in handy.


Imagine if there were 50 variables available to the user instead of just the 1. As is the case with a socket custom chat protocol interface script I'm currently writing.

Well. At least I won lunch.
Good philosophy, see good in bad, I like!