Zugg Software :: View topic - Class path specifiers

Posted: Mon Apr 03, 2006 4:35 pm

Along the theme of changing "wierdness" in zMUD with the new CMUD program, here is something else that I'm thinking of changing.

When you want to specify the full class path to a variable (or alias, etc), you use the / character and create something that looks like a full unix or dos file path. For example, if you have the class named "SubClass" within the main class named "Class1" and want to reference a varaible in the subclass, you can use the syntax:

#VAR /Class1/SubClass/varname value

OK, this is fine and logical. The problem comes in when using the . or .. to specify the root or parent path.

In zMUD, the use of . and / are mixed up. I remember having some discussion about this and people trying to convince me not to do it, but I don't rememeber any good reasons for doing this now. (maybe someone can find the original forum link for me).

So here are the proposed changes:

/varname

In zMUD, this refers to varname within the current class. In CMUD, this would refer to varname within the root class (package). This is a CHANGE in behavior.

./varname

In zMUD, this refers to varname within the root class. In CMUD, this would refer to varname within the current class. This is a CHANGE in behavior.

../varname

In both zMUD and CMUD this refers to varname within the parent class. This is unchanged.

Basically, these changes would make the class specifier the same as normal unix and dos filename paths. The parser doesn't care which way this is handled, but making it the same as normal paths would get rid of another "wierdness" in zMUD that is probably bugging people.

Comments?

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

IMHO... make the change.

Another case where the positives for removing 'wierdness' and making cmud more standard will outweigh the problems with minor incompatibility for zmud scripts.

Posted: Mon Apr 03, 2006 5:33 pm

I'm also hoping that not very many people use this specific syntax. Also, it's something that I might be able to "auto-correct" during the import of old zMUD scripts.

The main use of /var in zMUD is to force it to create a new variable in the current class instead of just changing the value of an existing variable. To make this situation easier I'm also planning to add a new command called #NEWVAR.

#NEWVAR varname optional-value

would create a new variable with the name "varname" in the current class. You can still use the class path specifier to create the variable somewhere else if you want. But unlike the #VAR command, #NEWVAR isn't going to look for an existing variable and just modify it...it will force a new variable to be created.

This should help fix the other big problem in zMUD where you think that you are creating a new variable, but in fact are just modifying the value of another variable somewhere else. Since zMUD searches in all enabled classes for matching variables, sometimes you might not have any idea where the variable is that is getting modified.

Packages made this situation worse in CMUD. It was too easy to have conflicting variable names and accidentally modify a variable in another package with the same name. Using #NEWVAR should help ensure that the proper variables get created initially.

The way I think about this is like when using "new" in VBScript, or "dim" to initially "declare" or dimension the variables. This is something that would be done in the package initialization event to ensure that the proper variables for the package get created.

Anyway, I thought I should post this here since it's related to the current use of /varname in the #VAR command to force a local variable to be created.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

I would go with the change of syntax - try and get auto-correct to work.

With the package library you really are going to want variables to 'play nice'. So I really think you should change the way #VAR works to only check the current class and it's parent classes. If you want to modify something in a completely different class then you have to explicity specify it with a /path/directive.

So if we have the following classes and variables:

/zugg/hp
/zugg/mana
/rainchild/hp

and I have a script in /rainchild/hp-monitor/ which does a #VAR hp 123 it should process like this:

"Is there a variable 'hp' in /rainchild/hp-monitor?" No -> "Is there a variable 'hp' in /rainchild?" Yes -> Assign 123 to variable /rainchild/hp

now if I then do a #VAR mana 456 it should process like this:

"Is there a variable 'mana' in /rainchild/hp-monitor?" No -> "Is there a variable 'mana' in /rainchild?" No -> "Is there a variable 'mana' in /?" No -> Create and assign 456 to variable /rainchild/hp-monitor/mana

At no point in time should I assign or even see the variables 'hp' and 'mana' inside the /zugg class.

.... the same goes for expansion, if I do a #SHOW @hp it should process like this:

"Is there a variable 'hp' in /rainchild/hp-monitor?" No -> "Is there a variable 'hp' in /rainchild?" Yes -> #SHOW @/rainchild/hp (ie 123)

if I wanted to manipulate the variables in the /zugg class, I would have to explicity do that, eg #SHOW @/zugg/hp

===========================

I do see one potential issue is when you want to do a 'say my hp is @hp' from the command line, in theory I should have to specify 'say my hp is @/zugg/hp' but we all know nobody is going to want to type all that... I'm not really sure what's the best thing to do in this case. Obviously, you could do the recursive search, but then what happens if there's 3 variables all called 'hp'?

So, we probably need to discuss this mechanism a little, I'm leaning toward some method of a package saying "I define the following 'published' variables" and letting them be mapped/redirected by the user... for example, the user could tell both '/raincihld/hp' and '/zugg/hp' to be mapped to a single variable called /hitpoints... or they could tell /rainchild/hp to use /zugg/hp.

I feel that the command line should probably be in its own class too. Eg if I do a #VAR blah 123 on the command line, it should create the variable in /system/command_line or similar. You then map /zugg/hp and /rainchild/hp to /system/command_line/hp and can do your 'say my hp is @hp'.

I don't know if that's too complicated or not - but I think it's possibly more confusing to have 20 packages loaded, 8 of which have their own '@hp' variable, and then which one do you pick?

Posted: Wed Apr 05, 2006 3:22 am

Here is what CMUD currently does when you ask for a variable like @hp:

1) First, it checks the current class
2) Next, it starts checking the parent classes (assuming they are enabled).
3) Next, it looks anywhere in the current package for an enabled variable in an enabled class tree.
4) Finally, it looks in the top level of other packages.

So as it stands, only top-level variables in other packages can be modified without a class specifier. Otherwise, all variables changes stay within your own package.

In a sense, the top-level variables in a package *are* the published variables.

Stuff on the command line goes into the package specific to your MUD character. So, if you have put all of your important stuff into other packages, then the command line won't really effect the other packages (except for top-level variables).

When searching other packages for top-level variables, they are searched in the order that they are loaded. When searching elsewhere in the current package for an enabled variable, the search is based upon the "priority" value of the variable (every setting has a numeric priority now).

Allowing variables to be "remapped" by the user would be way too complicated.

Also, remember that this applies to other settings too, not just variables. So top-level aliases are "published" from other packages and become the main commands used to manipulate the package.

The exception to this is that a package can have an option to publish everything no matter what class it is in. For example, the main "Default Settings" package does this so that the macro keys in the /Default Settings/Keypad class can still be used without having to put them into the top level. It's possible that I might add this "Publish" option to class folders as well so that you can really control what gets published and what stays local. But that's how it currently is working.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

Here's a link to the old thread talking about this when class paths were first propossed:

http://forums.zuggsoft.com/phpbb/viewtopic.php?t=9331

Rainchild and I were the ones in favor of using standard filesystem syntax, but apparently it wasn't possible due to some backwards compatibility problems.

Posted: Thu Apr 06, 2006 5:05 pm

Kjata, thanks very much for posting that link...you saved me a lot of time.

Looks like the original reason had to do with the old | syntax for class names. Also, it looks like the old parser couldn't tell the difference between / and no class at all and was treating @/varname the same as just @varname or something.

But it was a good discussion that pointed out some things for me to test and pay attention to. But it still looks like I can go with the "standard" syntax (which is the syntax recommended by Kjata in the original post in the first place ;)

OK, so it takes me 4 years to finally come around Wink

Magician Joined: 17 Oct 2001 Posts: 371 Location: USA

Sort of in line with the idea you mentioned before about top-level script objects being "published" from packages - is there a possibility about having the ability to "lock" variables and prevent them from being edited at all from other scripts outside of the package that the variable is in?

Posted: Fri Apr 07, 2006 6:28 pm

Just put the variable into a class folder within the package. Unless the Publish flag is set for the class folder then anything in the class will be private and not accessible to scripts outside the package. So no, there will not be an option for each setting...it's all controlled by what class you put the variable or alias or trigger into.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Can we get a read-only flag for those 'published' variables? You know how OO programming works, where a class has functions and properties which may have get/set members, or may only have get members and not allow set. That's what I want to see from a package. Any package can read my published variable, but if they try to write to it they will be denied unless they use the setter function (if I provide one).

Mostly, I might have a package:

/Rainchild/PromptUtilities which keeps @/rainchild/hp updated automagically

and then I might have a second package:

/Rainchild/AutoBot which could rely on @/rainchild/hp being correct and can make its decision process to see if you need to rest or if you are ok to move onto the next mob

Posted: Wed Apr 12, 2006 5:58 pm

Not in the first beta release, sorry, but it's a good idea for later.