Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
I was playing around trying to build a common UDF approach that could possibly be integrated into every UDF that would toggle "NoStringsInVars" and "Explicit" to "ON" for processing within the UDF and then if the option was not initially set turn it back off before the UDF exits.
The initial attempt is below. I found it interesting that the variable $Explicit is never caught as undimensioned in the initial usage. I would have thought that the UDF setting to "Explicit" would have occurred prior to placing the previous setting into the that variable $Explicit in the line:
code:
$Explicit = UDF_SetOptions("Explicit")
Is this approach of interest to anyone else?
Is the KiXtart parsing engine working as one would expect with regard to the $Explicit variable?
quote:toggle "NoStringsInVars" (sic)and "Explicit" to "ON" for processing within the UDF
I am trying to wrap my mind around why you would want to do this. I mean, if you want it set to on in every UDF, then why would you not want it on for the entire script? If anything, since the body of the script is likely to 100% yours but UDF might not, I would think that you would want the reverse, namely to turn it off for some UDFs.
Where you really need to be careful with "NoVarsInStrings" is where Execute() is used.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
My thought was that I wanted to code to a specific style and wanted my UDFs to be usable by anyone - those that set the options and those that do not. So each of my UDFs would set the options "ON" for my code incase the person using my UDF does not have them turned ON and then turn them back to the original state so that the balance of the person's code is not adversely affected.
Doing this would make UDFs easier to program. I think that I saw today where Lonk was coding something for Radimus so that his UDF would work if the person using the UDF had the options ON or OFF.
Well, if you want to SetOption('NoVarsInStrings','on') at the top of your UDF, that is easy enough and the function will return the previous state so you can undo it at the end. All you need to do is save the return for later processing.
In other words, if it was already 'on' when you set it at the top, you will just leave it that way else you will toggle it back off. Somehow I don't see where a UDF is needed to do that.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
A UDF is not really needed. One thought I had was that I could turn on more than one option as defined by some "best practice" definition. That way I could only use one line, the UDF, instead of multiple lines.
Like I said in my original post, I was playing around.
But I am more interested in the parsing logic that did not catch the $Explicit variable as not being defined.
Hehee... Yeah, I've always DIMmed before SetOption('Explicit','on') thinking that was how it had to be. Who'da thunk...
I think you would have to combine more than a few options into one UDF to break even on strokes. Won't do for golf. I think the UDF would confuse too many people.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
Shouldn't the SetOptions be local to a UDF? Otherwise it could override the global declaration. IF this is true your UDF_SetOptions is only locally setting it within the UDF UDF_SetOptions & as soon as this ends it reverts to the setting previously initialized in the UDF PadStr. Isn't this the appropriate action?
[ 23. September 2003, 04:42: Message edited by: Jack Lothian ]
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
Well my UDF does perform the SET local to the UDF. It set the options "ON" and then reverts to the original seting that existed before the UDF (PadStr) was called.
I am not quite sure where where the implementation is different from your description.
I'm lost. Don't see the issue, unless it is that you don't want to revisit and update old UDFs. The UDF (in my opinion) should be written to support the NoVarInStrings option. Then whether or not the script uses it, the UDF would work. Am I missing something here?
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
Jack,
quote:sets options local to 'UDF_SetOptions'
? You have me curious as to what you see that I may have missed. How do you see that working?
I love it when I write something of little consequence and everyone replies, but when I write something I think is important no one seems to really care .
[ 23. September 2003, 05:10: Message edited by: Howard Bullock ]
Your expertise & knowledge usually exceeds mine & I am thinking maybe there is something I am missing here but I look at your UDF
code:
Function UDF_SetOptions($a, optional $b) ; $a = "ASCII" or ; "CaseSensitivity" or ; "DisableDebugging" or ; "Explicit" or ; "HideCursor" or ; "NoVarsInStrings" or ; "WrapAtEOL"
& I see it essentially doing nothing because at the end of the UDF setoptions reverts to its incoming setting so if it was intially set to off it reverts to off. Maybe It is late & I am miss something.
PS: I just happen to be up at midnight because my wife is busy writing a paper & I was bored with television & reading so I thought why not check out the kixtart board. For you this is daytime but here it bedtime.
[ 23. September 2003, 05:23: Message edited by: Jack Lothian ]
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
Actually it does not work that way, Jack. The "$UDF_SetOptions = SetOption($a, $b)" statement actually sets the option GLOBALLY and returns the previous option setting to the UDF that called it, PadStr in this case. Then in PadStr the "NoVarsInStrings" and "Explict" options are in force until we call UDF_SetOptions again passing it the previous values set at the top of PadStr.
[ 23. September 2003, 05:22: Message edited by: Howard Bullock ]
I just did a quick re-read of the manual it seems either interpretation could be correct. I am not sure exactly what should happen?
Why should DIMing $NoVar make any difference? If you don't DIM $NoVar it becomes a Global variable but why should this affect a global state? I must say this is more complex than I thought.
[ 23. September 2003, 05:50: Message edited by: Jack Lothian ]
I just tested your routine. I must say I was totally off track here, I thought setoptions was local. Now I don't fully understand your original question? Are you suggesting kixtart usually resolves the right side of espressions before creating containers for the left side? It is a point I never thought about. Can we test it?
[ 23. September 2003, 06:16: Message edited by: Jack Lothian ]
we just discussed about that shortly yesterday with doc. I think when there is $-sign, kixtart takes the varname and searches for the equal-sign. if that is next, it means that there is going to be data written to the var so it will flush the var. in this case, it will actually create it. just-in-time declaration before crash, eh?