Variable scope issue.

[IanR]

Having succesfully tested a fairly complex routine as a separate main-program, I ran into problems when I wanted to make this routine a library-item for use by other code.

Basically, the issue is that the routine calls several sub-functions which need access to variables within the calling function in order to to do their job.

If the main routine is NOT a function in itself, then there is no problem, as variables declared in the main-program are global by default. However, if the main body of the routine IS a function, then the sub-functions are unable to access its variables, and fail.

A workaround is to declare all variables as Global, but of course that is not a very satisfactory solution as it would create a situation where those variables were also available "outside of the box" and might lead to clashes.

Basically, I need to declare variables in such a way that they are accessible in the function in which they are declared, plus any in any called sub-functions, however other branches of the program outside of this function-hierarchy should not have access to them. How do I achieve this? (I've tried all permutations of Dim, Global, and Local to no avail.)

Thanks, Ian.

[Jos]

Thats why we have parameters in functions ... or am i missing something ?

[IanR]

Thats why we have parameters in functions ...  or am i missing something ?

<{POST_SNAPBACK}>

Yes, namely that it would involve a total rewrite to do it that way.

Plus, my experience of MS Basic suggests that this way of working (passing the entire working-environment of a routine as huge strings of parameters each time any function is used) is one to be avoided at all costs. Better to avoid using sub-functions altogether than do that.

Edited December 29, 2004 by IanR

[Jon]

Yes, namely that it would involve a total rewrite to do it that way.

Plus, my experience of MS Basic suggests that this way of working (passing the entire working-environment of a routine as huge strings of parameters each time any function is used) is one to be avoided at all costs.  Better to avoid using sub-functions altogether than do that.

It's how most languages work.

Pass large parameters ByRef then you don't end up copying large strings around, you just copy a pointer which is very fast.

[IanR]

It's how most languages work.

It is how most dialects of Basic work (with the exception of the excellent RapidQ) though not how most "modern" languages work.

Having developed some large-ish programs with MS Basic, lack of a proper inheritance-mechanism in that venerable IDE meant that you had a choice of either:

1. To write your routines as one long, inseparable block of code.

Main problem here arises with sections which are only executed conditionally - you may end-up with, for example, an IF statement spanning hundreds of lines of code. This is extremely error-prone and almost impossible to indent/debug.

2. To divide your program into more manageable sections, and to pass the 'environment' varibles to each subsection of the code so each section 'knows what's going on in the big picture.' In practice the subprogram probably doesn't need the entire 'working environment' so you might be able to restrict the number of parameters to those which it actually needs.

Issue with this approach is that the amount of donkey-work (and the opportunity for mistakes) grows exponentially with the complexity of the program. This is because in order to add just one parameter to your subprogram's "environment" you need to modify not just its own header, but also the parameters of every single call to that subprogram, even those calls which are in other 'included' files. This soon gets to be even more 'out-of-hand' than writing as one solid block.

3. Use Gosub instead, and accept that no variables are ever local.

Purists will be aghast at this suggestion, but provided you maintain a rigorous variable-naming convention (which you should anyway)... it works perfectly.

Basically, the answers are either an inheritance-mechanism, or user-defined data-types, so the program's 'environment' can be easily passed to subprogams as a single 'object' whose properties can be modifed without having to re-write every call to the subprogram.

Just my ten cent's worth, anyway, not to be taken as a criticism but rather a constructive observation.

Ian.