Zugg Software :: View topic - Where is //Package/Class/Item syntax valid?

Magician Joined: 13 Oct 2000 Posts: 463

Which of these are legal (supported) syntax? I know some are pretty much for certain... I know others WORK, but I'm not sure if they are supported syntax (ie, they won't get broken). Some I haven't even tested to see if they work.

#CLASS //Package/Class
#VAR //Package/Class/Varname
#TRIGGER //Package/Class/TriggerID
#ALIAS //Package/Class/Alias
#ADDITEM //Package/Class/Varlist
#T- //Package/Class/TriggerID

Almost all of the discussion I've seen revolves around using the new syntax in @//Package/Class/Var references, and I know it works in the Class part of item defentitions (like #VAR name value default //Package/Class). But I haven't seen any discussion if it is supposed to be valid in the actual name of other item creation commands like #ALIAS, #TRIGGER, etc. Does this make the class part of a definition unnecessary? I'd certainly find it more convenient myself.

Raven

Magician Joined: 13 Oct 2000 Posts: 463

#ADDITEM and #DELITEM do not support this syntax. This means that non-unique variables are impossible to reference using these commands... if I have two variables, //PackageA/Class/Foo and //PackageB/Foo, there is no way to tell "#ADDITEM Foo" which one I am referring to.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

#class Foo
#delitem var thing
#class 0

Doesn't work?

Magician Joined: 13 Oct 2000 Posts: 463

Mmm, that does work, but it's pretty clunky. Also, I can find no confirmation that being the default class forces variables in that class to be READ first. It definitely makes that the default class for writing, but there's no documentation that I can see confirming it controls which variables are read. Lemme test it...

Yep, it works, at least for #ADDITEM (but presumably for other functions as well). Here's the test function I created (I just used the default Aetolia account):

#VAR Foo {In A} {} //Aetolia/A
#VAR Foo {In B} {} //Aetolia/B
#CLASS //Aetolia/A
#ECHO @Foo
#ADDITEM Foo {Another A}
#ECHO @Foo
#CLASS //Aetolia/B
#ECHO @Foo
#ADDITEM Foo {Another B}
#ECHO @Foo
#CLASS 0

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I agree it is pretty clunky, I would very much prefer changing the additem command to accept some other method of telling it what class/module to change. I do use these commands frequently...

Posted: Sun Nov 19, 2006 3:22 am

Er... as far as I'm aware it's not //Package/Class/Item but //ModuleOrWindow/Class/Item. There's a discussion about it here.

The easiest way to get around using this syntax that I've found, though, is just to not create variables with the same name in the same module :P Scripts use variables in their own module before those in another module, so just restrict your variables with the same name to different modules and you're good.

Interestingly, though, if you have a variable in another module or package and don't use this syntax while referring to it (even with the module and package sharing set up properly, though it shouldn't matter for settings in different modules but the same package) you get a variable not defined error. Is this intentional?

Posted: Mon Nov 20, 2006 3:41 pm

Fang is correct. It's //ModuleOrWindow/Class/Item. Remember the a "package" is just a *.PKG file on your disk...it's not something you can reference in a script.

Currently, the way to determine if something supports this syntax is to look to see if it's doing an implicit variable assignment. For example, #ADDITEM takes the name of a variable and is going to modify that variable with a new value. So this is doing an assignment to that variable name.

The only "assignment" command that supports the new syntax is #VAR. This is the same as the local variable restriction. Only #VAR knows about local variable assignment.

As long as it's not doing a variable assignment, then the syntax should work (for example, #CLASS and #T+ work because they aren't doing assignments).

This should be fixed in a future version.