Parameters for scripts?

[G Gabriel]

Re: Parameters for scripts?

Ira:
What we have here is a logic failure.
Your logic is:
Alpha, like any other software, is not 100% fool-proof.
I agree.
You went from there to advocate that to insulate yourself from alpha's unseen pitfalls, use functions instead of scripts.
I disagree.
And I disagree because functions (UDF) do not provide this insulation.
To illustrate:
Write these 2 functions:

FUNCTION test_funct AS C ( )
	dim shared woy as n
woy=-5
msgbox(str(woy))
END FUNCTION

FUNCTION test_funct1 AS C ( )
	week(date())
	msgbox(str(woy))
END FUNCTION

Run the first function, then the second. What do you get?
Same error as the script.
So much for bullet-proofing. All the UDF provided you with is a little extra work and a false sense of security.

[csda1]

Re: Parameters for scripts?

You went from there to advocate that to insulate yourself from alpha's unseen pitfalls, use functions instead of scripts.

Well you can disagree, but you are wrong. You did not follow the rules. You must dimension every variable (since you can't be sure of any other code's use) used in your code as local (doesn't matter whether script or function, but a function doesn't have to depend on shared or global variables to get it's parameters). Any that are not dimensioned as local are at risk, but this can be minimized by choosing very unique variable names for these higher scoped variables

The correct code for your second function is

FUNCTION test_funct1 AS C ( )
    dim woy as n
    week(date())
    msgbox(str(woy))
END FUNCTION

Done this way, woy returns a 0 (default value after a dim of a numeric), and is not affected by week() changing it's copy of woy

Take it one step further, and using;

FUNCTION test_funct1 AS C ( )
    dim woy as n
    val1=week(date())
    msgbox(str(woy)+","+str(val1))
END FUNCTION

returns this result "0, 52" in the message box showing both have their respective values.

[G Gabriel]

Re: Parameters for scripts?

Sorry Ira, I did it every way possible and the results are the same function or no function:

FUNCTION test_funct1 AS C ( )
	dim woy as n
	week(date())
	msgbox(str(woy))
END FUNCTION
'returns 0

But then, and to be consistent, try the same with a script:

dim shared woy as n
woy=-5
?woy
= -5
?week(date())
= 52
?woy
= 52

dim woy as n
?woy
= 0
'Same behavior

[jjfcpa]

Re: Parameters for scripts?

Ira & Gabriel

So much for trivial posts.

This thread has turned into a very important one for a newcomer like me. I have found your back and forth tit for tat very interesting.

Ira - I think I need to spend some more time with your tips article. Even though it was written some time ago, it seems very relevant to development of a programming standard.

Gabriel - Your posts definitely show that questioning someone's approach results in a better understanding of your programming technique and may very well result in better, more reliable, code.

Thanks for contributing and sharing your understanding of Alpha with those of us just getting started.

[Al Buchholz]

Re: Parameters for scripts?

But then, and to be consistent, try the same with a script:

dim [SIZE=5][COLOR=Red]shared[/COLOR][/SIZE] woy as n

shared is not local

try with with a local dim

dim woy as n

[G Gabriel]

Re: Parameters for scripts?

There is a lesson here not sure if it is obvious enough:
If you want to insure safer code do what alpha does (which is what I always do):
1-Before dimming a variable delete it just in case you dimmed it somewhere else
2-Always dim variables explicitly.
If you don't do these, alpha has some cushion but you shouldn't rely on that. Another subtle lesson (or two):
1-As you can see from the examples above, alpha when it comes across a variable, it checks the narrowest scope first.
2-The second, and a little troubling to me, when alpha deletes a variable, it deletes them one a time. What does that mean? It means the obvious: alpha creates a separate placeholder for each variable if both have the same name but different scopes. This will lead me to believe that for real security, you should use delete 3 or perhaps 4 times in a row to insure deleting all scopes. Might not be necessary if you are dimming a local and perhaps should be proportionate to the scope.
To illustrate:

dim global test_var as n=1
?test_var
= 1

dim shared test_var as n=2
?test_var
= 2 'alpha checked the narrowest scope first.

delete test_var 'this deleted the shared one but not the global one
?test_var
= 1

delete test_var 'this deleted the global one, 
'now there is no variable by that name
?test_var
ERROR: Variable "test_var" not found.

Ira has suggested before that delete "leaks".
Perhaps this explains it. That alpha deletes each separately.
Another bug.

[Mike Wilson]

Re: Parameters for scripts?

Perhaps this explains it. That alpha deletes each separately.

well this would certainly explain a few things that have caused me to pull some hair out!

[csda1]

Re: Parameters for scripts?

There is a lesson here not sure if it is obvious enough:
If you want to insure safer code do what alpha does (which is what I always do):
1-Before dimming a variable delete it just in case you dimmed it somewhere else

Absolutely NOT! Deleting a variable that you don't own, is seeding your own destruction. In other words, if not DIM'ed by your code, don't delete it! You will be deleting some other code's variable. And if you run multiple threads (e.g. two forms open at the same time), if both use the same variable (both name & scope) it, deleting in one could cause issues with the second.

You can freely delete any local variable that is not seen outside the present code's operation.

2-Always dim variables explicitly.

I've said it for 3 years, and described in my tips

....This will lead me to believe that for real security, you should use delete 3 or perhaps 4 times in a row to insure deleting all scopes. Might not be necessary if you are dimming a local and perhaps should be proportionate to the scope.

Again, if you didn't dim it locally. don't delete it unless you are 100% positive no one (Alpha or your code) ever uses that variable. All local variables are automatically deleted when the code (script or function) ends.

During development, perhaps in the interactive editor is the only time you might ever want to delete all scopes of a variable.

Also to delete a variable at a specific scope, just specify it's scope, as in

DELETE local variablename
DELETE shared variablename
DELETE global variablename

I've never validated this separate scoped operation, so take it as likely, but unchecked at the moment.

Ira has suggested before that delete "leaks".
Perhaps this explains it. That alpha deletes each separately.
Another bug.

I've never said that Delete leaks, and it works exactly as it is intended.

I did say, don't do it (because it is seldom necessary except in certain special cases, which Cal & I would be just about the only ones needing to do it in utilities), but there is no bug here. The fact that Alpha does occasionally explicitly delete variables at scopes other than local, is an issue, 100% resolved by DIMing all your variables as local (except as needed at higher scope)

As it is getting late, to all who celebrate the Holiday tonight,
have a very Merry Christmas! :)

[G Gabriel]

Re: Parameters for scripts?

What I said should be very clear, but evidently not so I'll say it again:
Delete x 'if x does not exist, no harm done
dim x

Say x exists in another script. THE OTHER SCRIPT WILL SAY:
delete x
dim x
There will be conflict, one thread, two or a dozen.

There is no leak. The issue is that not all variables with the same name and different scopes get deleted. Alpha deletes the first one it comes across, not all. Alpha starts looking in local, then shared, then global then addin.

It's a bug in delete and needs to be fixed.

[CALocklin]

Re: Parameters for scripts?

The following assumes that DIM is always used in the code BEFORE the variable itself is used - as it normally should be.

Situation #1: (read "script" as "script or function")

 
Script A sets variable X as follows:
Delete X
DIM GLOBAL X as C
 
Script B sets variable X as follows:
Delete X
DIM X as D

MAJOR HARM LIKELY TO BE DONE!
The above works fine AS LONG AS each script runs completely independently. However, if the GLOBAL X created in Script A is actually needed somewhere outside of the script (and otherwise it probably doesn't need to be global) then it won't work very well once script B deletes and recreates it as a local variable. Or, even if Script B never runs, if Script A is started a second time and expects to check for a previous value of X it will be deleted first - oops, that won't work!

You could take the attitude that only local variables should be deleted but (a) that's not really realistic and (b) it really doesn't serve any purpose.

Just because a variable is local in the current script doesn't mean it wasn't defined as global somewhere else - which is why automatically deleting them is not realistic. And I can't think of many people with even moderate amounts of code that remember every variable ever used in order to avoid re-using them somewhere else. In fact, I personally try to start all global variables with "g_" but even that gets missed once in awhile so I can't trust it 100%.

Situation #2: (no "delete")

 
Script A sets variable X as follows:
DIM GLOBAL X as C
 
Script B sets variable X as follows:
DIM X as D

In this case, the GLOBAL X remains at all times as a global variable AND the "X" in Script B that is dimmed local works independently of the global variable. And, if the GLOBAL X was set somewhere else previously, it isn't changed by the DIM statement in Script A. Adding a "Delete X" in Script B would serve no purpose other than deleting a shared or global variable that was defined somewhere else and might still be needed after Script B completes. To put that last sentence another way, using "Delete <varname>" before dimming a local variable serves no purpose because you're (hopefully) just deleting something that doesn't exist - if by chance it does exist, it isn't local and you're actually deleting something else that shouldn't be deleted.

Clarification: Alpha's help file isn't completely accurate. It says that "LOCAL" is the default when using "delete <varname>" but, as Ira said, it will actually delete the "lowest" variable it finds. If there is a local variable by that name, it will be deleted. BUT, if there is no local variable then it will delete any SHARED variable by that name and if it can't find a Shared variable it will delete any Global variable by that name. The only way to be sure you are only deleting Local variables is to be explicit:
delete local <varname>
Plain "delete <varname>" will delete the first <varname> it finds.

It wouldn't make sense to do this because a global variable and a local variable by the same name are really two different "things":
Delete GLOBAL X
DIM X as C
Assuming a global X exists, this would do the same thing:
Delete X
DIM X as C
and it serves no purpose to do this: (It works but serves no purpose since the local variable shouldn't exist unless you made a mistake and used the local variable in the script before dimming it. Even then it really serves no purpose.)
Delete local X
DIM X as C

I agree with Ira. Using "delete" as a standard practice is a bad idea. The ONLY situation where where you can safely get away with it is if you design your code so that all shared and global variables are only used within the local script - in which case you probably don't need shared or global variables.

The delete could be used in a single script where the same variable is re-used in multiple places but it's easier to just reset the variable as needed. For example, I use "qx" as my standard in FOR...NEXT loops but there really isn't any reason to delete it between loops because the next FOR...NEXT loop automatically resets it. (Just don't forget to use a different variable in a nested FOR...NEXT - BTDT!)

My thought on why Alpha uses 'delete' in Action Scripting:

Due to the fact that A/S can be combined in many ways, it's safer for Alpha to delete and re-dim each variable in each section of A/S. They may run into a situation where the same variable name is used for two different purposes/values and using 'delete' in each section eliminates that possibility. I'm not sure but I doubt that any single A/S action deletes the same variable twice.

This may be necessary in A/S because A/S can be thought of as individual pieces of code strung together to create one script. The problem is that the pieces of code can be strung together in so many different ways that it's almost impossible to determine which variables will or will not be used elsewhere in the overall script. Anyone creating their own individual xbasic script or function should not have this issue.

[G Gabriel]

Re: Parameters for scripts?

To follow up on what I said earlier...
I said perhaps you need to use delete more than once to insure deletion of all variables with the same names but different scopes.
As I thought about this further, I thought perhaps you need even more deletions..
But upon even further thinking, I came to the conclusion that one delete should do the trick.
First, it is too late (or early) to go through the reasoning and second I do not have access to alpha o illustrate, so will deal with this later perhaps in a separate thread. Suffices to say, it is not a bug. I've written to Selwyn but I think I already know what he will say.
Later...
-

[Mike Wilson]

Re: Parameters for scripts?

I have been playing with this for a good part of the morning. And I have to say this is really a mess!

Cal, I hate to challenge your words, I don't believe that discretely identifying the variable scope in the delete statement is valid. Run the following and see that stating discretely 'delete local <varname>' in line#14 does not delete the local variable. It actually does nothing. I do see the hierarchy of local then shared then global. But I also see the variable dimmed local will supercede the others.

In test section 2. I was playing with making a script to run all three needed deletes (local, shared and global) using a for-next loop and evaluate_template so to make this into a function for any stated variable name.

delete vtest1
delete vtest1
delete vtest1

dim global vtest1 as C="test_global"
msgbox("TEST1: Dim global",vtest1)

dim shared vtest1 as C="test_shared"
msgbox("TEST1: dim shared",vtest1)

dim vtest1 as C="test_local"
msgbox("TEST1: dim local",vtest1)

delete local vtest1
msgbox("TEST1: try delete local",vtest1)

delete vtest1
msgbox("TEST1: first delete",vtest1)

delete vtest1
msgbox("TEST1: second delete",vtest1)

delete vtest1
msgbox("TEST1: third delete")

' Test Section 2
dim global vtest1 as C="test_global"
msgbox("TEST3: Dim global",vtest1)

dim shared vtest1 as C="test_shared"
msgbox("TEST3: dim shared",vtest1)

dim vtest1 as C="test_local"
msgbox("TEST3: dim local",vtest1)

dim vdel_var as C="vtest1"
for i=1 to 4
	msgbox("TEST3: Delete #:"+str(i),vtest1)
	evaluate_template("delete "+vdel_var)
next

' this will error out
msgbox("TEST3: Final",vtest1)

[csda1]

Re: Parameters for scripts?

Hi Mike,

1st, I just want to say that your code for testing the process is just fine. Helps illustrates what I said would probably work, but I had not actually ever tested (But on the other hand should NEVER be needed).

Every case I have ever had says that the only place you actually need a delete is

• where you are running some other person's code that you do not know what type it is returning (in which case the return value should be placed into a local variable), or
• if you are using someone elses specification to generate code that you do not know if they've used before in another variable type (action scripts), in which case every variable that you might delete should be placed into properties of a very uniquely named pointer.

I have been playing with this for a good part of the morning. And I have to say this is really a mess!

Except for "delete local" not doing anything, there are no issues. There is no "mess".

And it doesn't matter that "delete local" doesn't work (although it should for consistency). If you are deleting a local variable using delete without a scope, you should know if your code ever DIMed the variable locally before the delete, so don't do the delete if it hasn't been dimmed locally.

...But I also see the variable dimmed local will supercede the others.

Yes, a local variable will always be accessed 1st if the others scopes exist. What are you trying to say? That's how it should be.

Everything Cal said (with the small exception of

The only way to be sure you are only deleting Local variables is to be explicit:
delete local <varname>

is 100% correct, and even the fact that dim local doesn't work isn't a big deal for reasons stated above.

As I said in an earlier post to the thread, I've never checked the scope parameter of the delete, but I didn't have to, as every delete I make in any of my code is always local to an existing dim'ed local variable.

Also, even if you have a local variable, you can still access any of the scoped variables by something like

?local_variables().varname
?session_variables().varname
?global_variables().varname

If you want to test for a scope of a variable, these will do it as well
?eval_valid("global_variables().varname")
?eval_valid("session_variables().varname")
?eval_valid("local_variables().varname")

[G Gabriel]

Re: Parameters for scripts?

Judging by comments made in this thread and others, the saga of "Logic Failure" continues, the plot thickens and widens and only goes to show lack of understanding of how alpha handles variables.

It's nobody's fault. Alpha doesn't explicitly state it anywhere but you could surmise it by alpha's behavior.

I don't want to get into confrontational debate with any. If anyone cares, will be glad to write about it perhaps in a separate thread.

[CALocklin]

Re: Parameters for scripts?

Cal, I hate to challenge your words, I don't believe that discretely identifying the variable scope in the delete statement is valid. Run the following and see that stating discretely 'delete local <varname>' in line#14 does not delete the local variable. It actually does nothing. I do see the hierarchy of local then shared then global. But I also see the variable dimmed local will supercede the others.

No problem. (Luckily it's almost the end of the year so this will probably be my only mistake this year.:D) I do wish I still had the script I used for testing (yes, I did run a test; it just wasn't a valid test) so I could see what I did wrong. You're absolutely right about Delete Local not doing anything. However, Delete Shared and Delete Global do work.

I did a bit more testing thinking that perhaps
DELETE <varname1> <varname2>
would delete <varname1> but apparently the "delete" only works as
DELETE GLOBAL <varname>
DELETE SHARED <varname>
DELETE <varname>

In other words, I tried to see if DELETE LOCAL VTEST would delete a varable named "local" and ignore the variable VTEST but it doesn't - anytime there is more than one 'word' after DELETE and the second word is not SHARED or GLOBAL, it does nothing.

 
DIM vtest as C="Mr. "
local = "Joe"
ui_msg_box( "TEST 1", vtest + local )
DELETE local vtest
ui_msg_box( "TEST 2", vtest + local )
DELETE vtest
'This fails:
ui_msg_box( "TEST 2", vtest + local )

And, I was shocked to see that you could actually have 3 variables with the same name defined in the same script! Not that it does much good because you can only access the "lowest" one dimmed. Perhaps you already tried something like this but try running the following script - basically running the first part of your script 'backward'. Every message box shows only the local variable:

 
DIM vtest1 as C="test_local"
ui_msg_box("TEST1: dim local",vtest1)
DIM SHARED vtest1 as C="test_shared"
ui_msg_box("TEST1: dim shared",vtest1)
DIM GLOBAL vtest1 as C="test_global"
ui_msg_box("TEST1: Dim global",vtest1)

Once the local variable is set, the local script can't see the SHARED or GLOBAL variable - which makes complete sense once you think about it. Similarly, if you define only a SHARED and GLOBAL variable (no local variable), only the SHARED variable will be available to the script.