Zugg Software :: View topic - [2.15] Dot notation of records is being ignored

Posted: Fri Dec 07, 2007 4:05 am

From Zmud:

#additem defs.norm defense

Would add "defense" to the value string of the "norm" key in the record variable "defs".

In Cmud it adds "defense" as a string addition to "defs". Effectively Cmud is ignoring the record "." notation and doing this:

#additem defs defense

I read through the changes to Cmud, but I didn't see anything about this notation changing, so I'm assuming this is a bug.

Posted: Fri Dec 07, 2007 7:56 am

I'm really torn as to whether this should be a bug or not. While the behavior is definitely different from that of zMUD, I'm not entirely sure that zMUD should have accepted such loose scripting. On the other hand CMUD interpreting the '.' as a space and changing the DB record to a stringlist can also have dire consequences.

Only Zugg can really say how easy/hard this will be to change.

If you need a work around you can do something like this:

Posted: Fri Dec 07, 2007 8:56 am

I believe that this worked in previous versions of CMUD, and should probably continue to do so. Some people get a lot of mileage out of it.

Posted: Fri Dec 07, 2007 11:41 am

It didn't work in 2.14a either, but that was the only version I had readily on hand.

Posted: Fri Dec 07, 2007 3:32 pm

Tech,

It's a matter both of conciseness and compatibility. I'm personally in favour of the shorter notation and as far as compatibility this code is used extensively in Larkin's Acropolis and so I'd prefer to not have to change it everywhere it was used.

By the way, I believe the below is the proper alternate:

Orig:
#additem defs.norm defense

Alternate:
#addkey defs norm %additem(%db(@defs,norm))

Edit: I'll add as well that it is non-functional as far as reading the variable goes as well. For example "#say @defs.norm" isn't displaying the value of the norm key as it should. I'm going to have a ton of stuff to change if this never gets fixed.

Novice Joined: 12 Oct 2006 Posts: 49

Think I was told in earlier version of CMUD2 to use @{defs.norm} now and not just @defs.norm. Would that make a difference for you?

Posted: Fri Dec 07, 2007 4:10 pm

I tried using the syntax you noted above, but it didn't work. Did it work for you in previous versions of CMud?

Posted: Fri Dec 07, 2007 4:52 pm

Lina - that's true only in cases where the @ symbol is needed and when the variable name is some kind of complex combination of strings. Neither of those is true in this case.

Posted: Fri Dec 07, 2007 6:11 pm

This kind of nested syntax is not going to be supported in this public version.

When the hash tables were added for speed improvement to string lists and database variables, it introduced a problem with nested lists/databases. When you use

#additem defs.norm defense

you are creating a string list within a database variable record. And CMUD cannot create a hash table for the string list in this case. In other words, CMUD can only create hash tables for string lists and database variables for the main variable setting. In the above example, @defs is the main variable. So CMUD can create a hash table for @defs. But it cannot create a hash table for @defs.norm because CMUD can only store string values within a hash table, and so @defs.norm needs to be a normal string value and not a string list.

In the future I will look into this syntax to see if I can still support it in the "slow" method that CMUD used to use for string lists and database variables.

You can get around this using the %additem as mentioned above since the %additem function can return a normal string value. But I wanted people to be aware of the limitations of this system so that you'll understand why you will not get any speed benefits when using nested lists/database variables. In fact, it will probably be a bit slower since CMUD will need to do a lot more conversions between hash tables and string values.

Anyway, this is on my list to look into in the future, but it's not going to change for this public release.

Posted: Fri Dec 07, 2007 6:38 pm

Thanks for the explanation Zugg. Your thoughtful and descriptive replies puts you a step above the rest.

Knowing now what you explained, I'd rather convert all my usages of this to an alternate method rather than suffer a speed penalty. I'd put speed of execution high on my list. I'd rather see this syntax removed from CMud than to be included with a speed penalty. A note in the upgrade guide and an extra item in the compatibility report would be sufficient.

By the way can anyone think of a quick way to locate these instances in my code? I could do this with a regular expression search, but nothing comes to mind with the standard search provided in the editor.

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

You could click onto the XML tab of a class, copy the XML into your favourite regex app, make the changes then copy it back. Would mean you could do every trigger in one go

Posted: Fri Dec 07, 2007 7:05 pm

I like that. Emacs should be able to make sort work of the changes. Is it just that easy to copy it back into that tab? It won't mess it up copying XML into the XML class tab will it?

Posted: Fri Dec 07, 2007 7:38 pm

I'm thinking XML export then, regex on the file will be the quickest overall way.

[Edit] Ninja strikes again.

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

ReedN, I know that Larkin's Acropolis has a lot of usage of the string list inside of a database variable.

Here is something helpful for getting rid of a LOT Of this usage. These presents aren't in the help file yet.

Posted: Sat Dec 08, 2007 3:36 am

You could also use Lua, which allows nesting tables Twisted Evil

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I think I am fine with the dot notation not working with #ADDITEM and #DELITEM. I am however finding some oddities with the notation that affect the ability to use COM objects. I am not sure when they were introduced since I tend to avoid both the dot notation and COM like the plague.

Posted: Sun Dec 09, 2007 12:27 am