Zugg Software :: View topic - Questions on scoping and the current class

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

In a thread on enabling and disabling classes, Zugg posted some info regarding scoping of names:

Posted: Tue Nov 06, 2007 6:13 pm

You are correct that each module and window keeps track of it's own "current class". The "current class" is set with the #CLASS command. The current module is set with the #MODULE command (and the current window with the #WINDOW command obviously).

When you switch to a module/window using #MODULE/#WINDOW, the "current class" becomes whatever the last current class within that module. For example:

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Please understand that I'm not advocating for any changes at the moment. Just trying to understand how it actually works.

Most of these questions were popping into my head as I was trying to design a couple of packages for eventual upload to the library, and I knew in advance that I couldn't rely on just making unique names for everything (because the end user can define names and load other packages over whose names I have no control). I kept knocking my head on scoping questions, or finding behavior that seemed odd, because I didn't understand the underlying semantics.

Follow-up questions:

There is an explicit syntax for referring to a setting within a specified module and class: //Module/Class/Subclass/Setting. Is there an explicit syntax for referring to a setting within a specified PACKAGE, module, and class? (If so, I can write a package that will never 'litter' other namespaces by mistake, even if some of its settings get deleted unexpectedly, or module names conflict in simultaneously-loaded packages)
Can I rely on names within my package to eclipse names outside my package? As a specific example, if I have an alias 'foo' in a local module, and I call it from an alias in a global module of the same package, is there any chance that some 'foo' in another package might get called by mistake? (Note that this problem arises even if I call it as //privateModule/foo, it's just less likely to conflict)
Are '#var myClass/myVar foo' and '#var ./myClass/myVar foo' equivalent? (Namely, changing 'the myVar variable in the myClass subclass of whatever class is current in this module')

I may put some test cases together to verify the behavior you've specified above. And I will be happy to tackle a FAQ on this subject, on a schedule to be determined by various RL activities. Wink

However, you've done most of the heavy lifting in that first response.

Posted: Tue Nov 06, 2007 9:08 pm

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Posted: Tue Nov 06, 2007 10:29 pm

In my current test script I have an alias that will execute a script or evaluate an expression and then compare it to the "correct" value and color the line red or green and count the number of failing tests.

So really, almost anything you come up with will be useful. For example, I currently have simple stuff like this:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Since I have been playing around with a lot of weird context/scope issues and since this topic may get assembled into manual document I thought it best to put my general take on just what I am thinking in terms of these things here.

My other topic about functions and context is actually misnamed. The function is contexted correctly because the #SHOWs appear in the correct window, the scope though is not right. Also Zugg mentioned that aliases may have the same behavior and I haven't actually tested with those to see if it makes sense. I just going to give a few generalities to this so everyone can get and idea what I am thinking.

First nothing happens without a window. Every script no matter how executed is attached to a window. So in that regard the CONTEXT of every script is the window that caused its execution. The context determines where outputs such as #SAY and #SHOW are displayed, #ECHO of course still goes to the focused window. Focus is a seperate issue and should not affect the context where a script executes.

Second, every script should have a SCOPE of whatever module it is in and everything that that is in scope to its execution context. To be very clear when an alias in a module is executed its scope should be everything in that module and everything that is in scope to the window that is the context the alias is being execute in. This means that CONTEXT helps determine scope.

Third is FOCUS. Focus should only be considered when an alarm in a published module is ready to fire. By published module I mean any module that is within the scope of more then 1 window. The alarm in that state has to be instanced so that there is only 1 countdown time on it, and doing #ALL "#ALARM" should display the alarm in all windows with the correct time. Every window that has that alarm in scope should be able to adjust it with #T±, #SUSPEND, #RESUME, %alarm, etc. When it fires though it checks the focus to determine its context. Such an alarm should be the only thing that has look at focus.

One thing I haven't played around at all with is the status window, I believe there is still only 1. Since settings could be defined for it in multiple windows it probably needs someone to really throw a few curves there, especially with functions that can execute script.

A small furtherance based on these concepts is buttons and status bars in a published module. These were recently enabled to work with a window allowing us to publish a paackage that has buttons for the session window. Technically the buttons should be displayed in every window that has that setting in scope. Because the captions can execute scripts through a function or %exec we need to be clear that the executed script has a context of the window displaying that instance of the button/status bar.

Final item, barring any in scope definition of a default class when an executing script creates a setting it should be created in the window that is the execution context. This mean that an alias in a published module will create a variable in the window calling the alias if no defined default location is set. I would want to further this slightly by saying that the window's defined default location is first, second is any belonging to the module containing the alias, and finally it is first found within scope of the execution context. I am not sure that is really doable with how the Set as Default when Execution, #CLASS, and #MODULE command s are currently stored.

That is just my group of thoughts from some of the tests I have been doing. I know the last time this stuff was really discussed the package and module design was the main thrust. I think we need a clear view of context as well as scope, and because I firmly believe that context should be part of defining scope I would like to see it all put together as a single manual section.

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Wed Nov 07, 2007 6:19 am

Rather than thinking about which window #SHOW displays it's output, I actually think of "context" as: "where does a variable get created". Consider the simple '#VAR varname value' command. If this is placed in a script, and the variable doesn't exist anywhere in the current scope, then where should it be created? That is determined by the "context" in my definition of context.

Thus, a trigger creates the new variable within the window that caused the trigger to fire. But an alias creates the variable within the current class of the module that contains the alias.

With this definition of context, a script without a window (like an alias within a module) still has a context, even though #SHOW might never be used in that script. In the case of a setting with no window (like an alias within a module), using #SHOW will send the output to the currently focused window (since there isn't anyplace else for it to go). The same is done for an alarm within a module that doesn't have it's own window...the result of #SHOW will go to the focused window, but a #VAR command will create the variable within the module that contains the alarm.

So, when creating test scripts, I think it is important to test *both* the creation of new variables as well as the destination of the #SHOW command.

And yes, I agree that "scope" is slightly different than "context". Scope determines the order in which CMUD looks for other setting references (like where it looks for an existing variable of a given name). There are two ways scope is used in CMUD. I call them "FindSetting" and "Setting.InScope".

"FindSetting" searches the database for a setting of a given name. First is looks in the current class of the current module (which is the same as the "context" of the current script that is running). Then it looks in the parent class, then it's parent class until it gets to the root of the current module. Then it looks in any enabled class within a Global or Local module within the same package. Then it looks within a Global or External module within any other package. The order in which it searches these other modules is not defined, but it always looks in the current package before looking in other packages.

"Setting.InScope" takes a particular setting, like a trigger, and determines if it is "InScope". This means, "is this setting visible to the current script"? For example, when a line of text is received into a particular window, CMUD loops through all triggers in priority order and asks whether each trigger is "inscope". If a trigger is "inscope" then it's pattern is tested against the line of text received. When CMUD displays the buttons in a window, it actually loops through all of the buttons in priority order and asks which buttons are "inscope" for that particular window.

So, "InScope" first looks to see if the setting itself is enabled. If so, it looks at the class containing the setting to see if the class is enabled. This continues to each parent until you get to the top level window/module. If everything is enabled, then we check to see if the Module/Window containing the setting is the same as the current module of the "context" (for example, the "context" is the window that received the text, or the window that is displaying the buttons). If the module is different, then we check to see if it's in the same package as the current context. If so, then it returns true if the module is local or global. If the module is in a different package, then we return true if the module is External or Global.

That probably adds more confusion, but that's more of the terminology that I tend to use.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Ok...Since this is sort of a tracking thread for creating the automated test of scoping rules, I'll put the info here.

Summary

I've created the beginning of an automated test, using variables to probe the visibility of various modules. Basically, I create an identically-named variable (testVar) in a whole bunch of places. Each copy of the variable contains its own location (module and class names). Then, I repeatedly (a) print the value of @testVar, and (b) #unvar it, using the value to make sure I get the right one (due to the fact that #unvar isn't currently working for stuff in other modules, etc.). The result is a list of the scopes that the system is checking for @testVar, in the order that it checks 'em. Or that's the theory, anyway.

Implementation

Currently only partially implemented. To replicate my current setup:

Create a new, empty session named "ScopeTest". This will have the default window named "ScopeTest" and nothing else. (Point it to whatever server you want - we'll only use it offline. It's just a pain to do all the work below in the untitled session each time you want to test)

In the session, create a package "ScopeTest01" with four modules: External01, Global01, Local01, and ScopeTest01. The external/local/global modules are empty, but with the obvious options set. The ScopeTest01 module (also global) has the good stuff:

Code:

<?xml version="1.0" encoding="UTF-8" ?>
<cmud>
<module name="Global01" global="true">
<uid>{C8C342AA-B81A-42D2-A0CF-D5279923972E}</uid>
</module>
<module name="Local01">
<uid>{C50CFB83-5169-4B91-B47A-07A68559B0EB}</uid>
</module>
<module name="External01" external="true">
<uid>{C24B4371-402F-4D89-ACC5-7B8DC94A5980}</uid>
</module>
<module name="ScopeTest01" global="true">
<uid>{3FABEC08-3B84-4207-B6B8-CB493AB02F0B}</uid>
<packages>ScopeTest02</packages>
<alias name="setupVars01">
<value>#show "Doing setupVars01"
; 'Current' module for this alias, whatever that is. This may get overwritten!
setupModuleVars01 0
; Module for the current window, if accessible.
setupModuleVars01 %window
; Module containing definition of this alias
setupModuleVars01 ScopeTest01
; Global Module in defining package
setupModuleVars01 Global01
; Local Module in defining package
setupModuleVars01 Local01
; External module in the other package (since it's visible here)
setupModuleVars01 External02</value>
</alias>
<alias name="showScopeTest01">
<value>#say "*** showScopeTest01 - root level"
#while (@testVar) {
$tv=@testVar
$mod=%item($tv,1)
$cl=%item($tv,2)
#say %concat("*** showScopeTest01: ",$tv)
#debug module $mod class $cl
#module $mod
#class $cl
#unvar testVar
#class 0
#module 0
}</value>
</alias>
<alias name="stepScopeTest01">
<value>$tv=@testVar
$mod=%item($tv,1)
$cl=%item($tv,2)
#say %concat("*** stepScopeTest01 - root level: ",$tv)
#show module $mod class $cl
#module $mod
#class $cl
#unvar testVar
#class 0
#module 0</value>
</alias>
<alias name="clearVars01">
<value>#show "Doing clearVars01"
clearModuleVars01 0
clearModuleVars01 %window
clearModuleVars01 ScopeTest01
clearModuleVars01 Global01
clearModuleVars01 Local01
clearModuleVars01 External02</value>
</alias>
<alias name="setupModuleVars01">
<value>; setup vars in the named module
#module $mod
#class 0
#t+ ./testVar
#var ./testVar %concat($mod,"|0")
#t+ ./Class01
#t+ ./Class01/testVar
#var ./Class01/testVar %concat($mod,"|/Class01")
#t+ ./Class01/SubClass01
#t+ ./Class01/SubClass01/testVar
#var ./Class01/Subclass01/testVar %concat($mod,"|/Class01/Subclass01")
#module 0</value>
<arglist>$mod</arglist>
</alias>
<alias name="clearModuleVars01">
<value>#module $mod
#class 0
#unvar ./testVar
#delclass ./Class01
#module 0</value>
<arglist>$mod</arglist>
</alias>
</module>
</cmud>

Create a second package "ScopeTest02", with modules External02, Global02, Local02, ScopeTest02, similarly flagged as external/global/local/global respectively:

Code:

<?xml version="1.0" encoding="UTF-8" ?>
<cmud>
<module name="ScopeTest02" global="true">
<uid>{78C54AA2-835E-42B5-9220-FFF1FAAA29B1}</uid>
<packages>ScopeTest01</packages>
</module>
<module name="Local02">
<uid>{3FE38BB2-D08F-4000-ABE7-D88485EDF165}</uid>
</module>
<module name="Global02" global="true">
<uid>{1F52091B-77BD-445D-8BCE-4CFE145A7457}</uid>
</module>
<module name="External02" external="true">
<uid>{0AD89609-DB94-4067-B4EE-B6D878988866}</uid>
</module>
</cmud>

Mark package ScopeTest02 as enabled for module ScopeTest01, and package ScopeTest01 as enabled for module ScopeTest02. Both packages should be enabled for window ScopeTest.
Screenie of the final setup in Package Editor:

EDIT: Improved this description after I remembered how to get XML for a whole package, not just a module.

Execution

NOTE: All tests shown below are run under 2.11. So the 'current module' for all settings (aliases, etc.) which we call from the command line will be the main window (ScopeTest)

To set up the (first, partial) test, type at the command line:

Posted: Wed Nov 14, 2007 7:08 pm

Wow, excellent work. I'm in the middle of playing with your scripts. I'll post answers to your questions as I get to them. Here is the first one:

Posted: Wed Nov 14, 2007 7:10 pm

Posted: Wed Nov 14, 2007 7:19 pm

When running "showScopeTest01" (you have a typo in your post and called it showScopeVars01) I get the following output in v2.12:

Posted: Wed Nov 14, 2007 7:23 pm

Posted: Wed Nov 14, 2007 7:25 pm

Also, in 2.12 I add the following event which helps me remember how to use these tests. This event is created in the ScopeTest01 module.

Posted: Wed Nov 14, 2007 7:32 pm

Hmm, something really strange is definitely happening here. I just reloaded and ran the test again and got this result:

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Posted: Wed Nov 14, 2007 8:10 pm

Found it! Yep, this was a serious problem. Each thread stores it's execution context (the module/class to execute within). This wasn't getting reset across shared threads taken from the thread pool. So sometimes the "showScope01" alias was getting executed from a different context (like from within ScopeTest01 instead of the regular ScopeTest window). So that explains the variable results. I've got this fixed now in 2.12.

I also added a new predefined variable called %module which returns the name of the current module. Remember that %class returns the current class (including the module). These variables can be used to save/restore the current module and/or class. Since %class includes the module name, doing #CLASS %class will also set the proper module. But I added %module so that I could easily write a debug message showing which module was actually active at the beginning of the alias, and that's how I tracked down the bug.

Still not getting the Local01 variable to delete yet, so still working on that.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Posted: Wed Nov 14, 2007 8:15 pm

Posted: Wed Nov 14, 2007 8:31 pm

OK, found it. The problem with deleting variables was that the #UNVAR command didn't support paths. So doing '#UNVAR ./testvar' wasn't handling the ./ properly. Once I fixed the bug with the thread context, the clearVars01 wasn't deleting *any* of the top-level variables. And this was because of the ./ problem with #UNVAR. I've got that fixed now, and now your test is working great for me here.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Posted: Wed Nov 14, 2007 9:03 pm

Yep, I fixed all of the #UN commands at the same time.

Posted: Fri Nov 16, 2007 12:11 am

OK, after our other scoping discussions I have made some changes to v2.12. Here is the result of running the scope test scripts given above in v2.12:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I absolutely agree with the order for searching! Next up order of creation.