Zugg Software :: View topic - [2.10] Creating variable NAMED '//module/name'

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

Summary

It is possible to create a variable with slashes in its name using #var //module/name value where 'module' is the name of a module that does not exist. The result is a setting in the root level with the name '//module/name'. This should not happen.

Procedure

Open CMUD
Dismiss the Sessions window by pressing ESC
Type the following at the command line and hit Enter:

Code:

#var //foo/bar baz
Open the Package Editor by pressing Ctrl-G. Verify that there is a variable in the root level of the untitled window with the name '//foo/bar' and the value 'baz'.

Notes

Oddly enough, the variable named '//foo/bar' CAN be accessed with @//foo/bar. However, if you ever actually create the module foo, you will no longer see it (since the actual foo module doesn't have a 'bar' variable in it). Also, '#unvar //foo/bar' will not delete the value.
A different, but related behavior can be seen with the following command:

Code:

#var //foo/bar/baz bag'

When the Package Editor is opened, you will find that there is a variable in the 'bar' class in the untitled window, with the name 'baz' and the value 'bag' (also shown in the screenshot above). In this case, CMUD seems to throw away the name of the non-existent package (foo) and just create classes and subclasses. In other words, it behaves as if you had instead typed '#var /bar/baz bag'.

I have not decided if this is right or not (since there is no good way to indicate that a #var command FAILED), but the behavior of the main procedure should at least match this. In other words, for consistency, '#var //foo/bar baz' OUGHT to result in a 'bar' variable at the root level of the untitled window.

Another possible solution is to dynamically create the foo module in some default location (like classes and subclasses are dynamically created). Again, not sure if that would be right, and it could be fraught with peril. Please discuss.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I would say for consistency creating a module in the package of the window is the way to go. The default option for a new module is Local, so I can't see a problem arising out of creating it on the fly the same way a class can be created.

Posted: Sat Nov 10, 2007 12:42 am

Yep, I'll fix it to create the non-existent module. Added to bug list.