Zugg Software :: View topic

Posted: Fri Apr 21, 2006 1:23 am

I was thinking a bit more about the #NEWVAR command last night in the shower.

To refresh your memory, the idea is to have a new command for *creating* new variables, compared to the existing #VAR command which can both a) change the value of an existing variable or b) create a new variable.

The proposed syntax for #NEWVAR was this:

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

Yes!

Especially if you support the "#INT $blah = 2" syntax as most people are familiar with.

Make the '=' sign optional, so "#INT $blah 2" also works, but I think most people would prefer to be able to specify the '='.

I mean it's kinda weird that it's not "int blah = 0;" but I can cope, it's zScript, not C++ ;)

Will it be '#float' or '#double'? Or both? I prefer double myself. I guess they are technically two different things, so if you have floats and doubles, then that makes sense to have both.

What about the 64 bit math? Will #INT be 32 bit and #LONG be 64 bit?

Also can #STRINGLIST be shortened to #STRL?

Beginner Joined: 24 Nov 2002 Posts: 20 Location: Australia

On behalf of those of us who are nowhere near as coding savvy as Rainchild or Zarquan or most of the other guys with high post count - it would be nice, as long as the documentation was nice and complete so we could try and remember what to use when. Current mudding belief is that if you want to learn how to code well you use something like Mushclient, but if you want something thats relatively easy to learn but is still robust, powerful and capable of pretty much anything you use zMUD and thats something I wouldn't like to see disappear with CMUD.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

More concise, a better conveyance of the information and the intended purpose, I likey! I assume declaration+assignment with the multiple variables would be possible, too? May want/need the requirement of at least the equal sign if not some sort of bracketing rather than assuming that the next word is the value of the variable:

#INT hp=5 {maxhp 22} {mana=35} count

Speaking of variable typing, would STATIC be feasible as a feature?

Posted: Fri Apr 21, 2006 4:46 am

I'm not sure I understand what you mean by "STATIC". What are you looking for here?

Also, I didn't intend #INT, #STR, etc to also set values. I'd like people to stick with normal variable assignment for values. The idea is that #INT, #STR etc would "declare" the variables to the compiler, much like

int varname;

does in C/C++. These are compiler declarations and not really runtime statements for setting values. But I guess if the demand was there, then I could add it at some point.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Hmm, surprised you've never heard the term...maybe Delphi/C++ use different terminology or simply don't use this concept. Basically, a static variable is a local variable with global persistence. As a local variable, it's only available to whatever function created it. Like a global variable, however, it stays in memory once that function has finished executing this iteration.

I've mostly seen static variables used as counters, but they can be for just about anything.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Personally, I almost never create a variable from within my scripts. I do all my variable creation in advance. I can see that I will be doing some variable declaration in my scripts to take advantage of the local variables, but beyond that I can't really see too much need to create variables all the time. So I would perfectly happy withe the new commands here as long as they recognize the local $ indicator and did a basic intitialization of 0 and "".

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

Posted: Fri Apr 21, 2006 4:38 pm

Delphi doesn't have "static" variables either. They are either global, or local to a routine or class, or a data field of a class. But I know what you are talking about. Unfortunately, there is no way to have "static" local variables. Local variables exist on the runtime stack and they go away when the routine ends. The only way to have persistence is to store the data into the internal variables structure in CMUD, which is basically the same as the normal variables in the database.

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

I'd really like the #INT /etc to allow assignment ... in c/c++/c# you can go:

int i = 0;
string foo = "bar";

I mean you can go:

int i;
string foo;
i = 0;
foo = "bar";

or in CMUD

#INT $i
#STRING $foo
#VAR $i 0
#VAR $foo "bar"

but that's a waste of time/lines/typing... I mean 99% of the time you create a variable, especially a $temporary variable, you will want to assign a value to it right then and there

I see the #INT/etc more like a combo between the #VAR command than the #NEWVAR command - create the variable if it doesn't exist, and set a value if you want.

I would like to see the ability to do both local and normal variables with it eg:

#INT @hp = 123
#INT $i = 0
#STRING foo = "bar"

And as matt suggested, it would be nice to be able to do multiple assignments on the one call - eg:

#INT $i = 0, $j = 1, @hp = 123, @maxhp = 444

Surely a whole lot better than writing:

#INT $i
#INT $j
#INT @hp
#INT @maxhp
#VAR $i 0
#VAR $j 1
#VAR @hp 123
#VAR @maxhp 444

Not only is it less confusing when debugging to do the assignment at the time of the variable's creation, but it makes the scripts a lot more compact too.

Newbie Joined: 19 Mar 2006 Posts: 6

Posted: Sat Apr 22, 2006 5:03 pm

Also, keep in mind that I don't want people to get completely carried away with variable "types". If you are assigning 123 to a variable, then CMUD already knows that it's an integer. You only need to specify types when there is ambiguity. I don't want CMUD scripts to start getting to complicated and looking like a C program...this will turn off novice users who are drawn to CMUD because it's supposed to be easier to script than a formal programming language.

Also, you need to watch your syntax when using the @ character. Your example of

#VAR @hp 123

and

@hp = 123

are wrong. The $ is needed for local variables to distinguish them from normal variables with the same name. But with normal variables, you don't use the @ unless you are doing indirect variable assignment. In other words, the correct syntax is still:

#VAR hp 123
hp = 123

If you use @hp, the CMUD is fetching the value of @hp and then using that value as the name of the variable to set.

Finally, remember that you do NOT have to declare a variable before using it. The purpose of #NEWVAR, #INT, #STR, etc was to force the creation of a new variable in the current class without performing any search to see if a variable already existed in a parent class. The intent was not to start making you declare everything. In a script, if you do something like this:

$local = 123

then this creates a new local variable called "local" right then and there and assigns 123 to it. There is no need to declare it with #INT or anything.

After reading the confusion that this has all caused, I'm tempted to leave out the #INT, #STR, etc commands and just stick with the normal type-casting functions. After all, if you want to assign 123 as a *string* to a variable, you can already do this:

#VAR strvar %string(123)

and, of course, you can still use #VARTYPE to change the type of any variable to something else.

I know that you all mean well in your suggestions. But I just can't completely change the CMUD syntax into something completely new and I can't have CMUD looking more and more like C/C++. For example, in the suggestion:

Posted: Tue Apr 25, 2006 2:53 am

Beginner Joined: 11 Jun 2006 Posts: 20

Uggg!

Why are you making people learn about types for zmud?

zmud was my gateway into programming, if I had to know about the difference between an int and string, I doubt I would have gotten started.

Also, how would this work if you need to make a new package?

#package GUI ?

hmm, just read some things and see my concerns are allready taken care of. Well, just wanted to remind you how great your product is a gateway drug to coding.

Posted: Mon Jun 12, 2006 12:39 am

Did you read the whole thread (and some other threads)? CMUD is not requiring types. They are an optional feature to allow better control in complex situation when the type of a variable matters. I am not implementing the #INT, #STR, etc. Just #NEWVAR.