 |
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
 Posted: Wed May 19, 2010 10:34 pm
Case sensitive database variables and string list in 3.18
|
I think we talked about this a long time ago when I first started using hash tables for CMUD database variables. But the issue has come up again with the new json SuperObject code for allowing nested string lists and tables.
The issue is that json is case sensitive. This assumption is coded at a low level within the SuperObject code and it very difficult to change. So this means that the next version of CMUD will likely be case sensitive.
What does this mean? Imagine the following database variable:
| Code: |
| #VAR dbvar {Name=Zugg|Class=Warrior|Race=Dwarf} |
In the new version you will get this:
| Code: |
#SHOW %db(@dbvar,Name) --> Zugg
#SHOW %db(@dbvar,name) --> null
#SHOW @dbvar.Name --> Zugg
#SHOW @dbvar.name --> null
#SHOW %delkey(@dbvar,name) --> Name=Zugg|Class=Warrior|Race=Dwarf
#SHOW %delkey(@dbvar,Name) --> Class=Warrior|Race=Dwarf |
I don't see any way to get around this and I hope this doesn't cause a lot of problems for people. For people who need case insensitive keys, you can just force them to upper or lower case when you enter them into the database variable.
The same is true of String Lists using the %ismember function. For example:
| Code: |
#VAR list {a|b|c}
#SHOW %ismember(@list,b) --> 2
#SHOW %ismember(@list,B) --> 0 |
As much as I like case-insensitive languages (like Delphi), it's probably time for zScript to enter the modern world with all of the rest of the programming languages that *are* case sensitive. It also makes zScript more consistent with Lua tables.
My only big concern is that CMUD itself might be using string lists or database variables internally or in the mapper that require it to be case insensitive, so I'll need to look for problems like that.
Sorry to anybody this will screw up. On the other hand, there are probably an equal number of people who will rejoice with this change. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu May 20, 2010 7:47 pm
|
Err...NEVERMIND :)
I was thinking about this today and while looking at the code and fixing some problems with the custom sorting, I realized that I could use the custom sorting hooks to add a case-insensitive option.
So you can ignore the previous post. When using CMUD string lists and database variables, the default in the new version will still be case IN-sensitive. Only when creating actual JSON objects will case sensitive be enabled by default. And you'll be able to control this option for each string list and database variable (similar to how the Sort option is currently set).
Making a string list or database variable case-insensitive has a tiny performance decrease just because the hash function needs to convert each letter in a key to uppercase within the internal search tree. But this is very minor.
I guess posting something like this helps my subconscious figure out a solution :) |
|
|
|
|
MattLofton
GURU
Joined: 23 Dec 2000
Posts: 4834
Location: USA
|
Posted: Thu May 20, 2010 8:51 pm
|
It does! We have whole weeks of blog posts from when you'd get sick as evidence! 
|
|
_________________
EDIT: I didn't like my old signature |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu May 20, 2010 11:01 pm
|
Of course, once I solve one problem, another problem rears its head.
Now my problem is with the \ escape character. JSON uses the \ as the escape, so if you want embedded quotes, you do this:
| Code: |
| var = {"key": "value with \" quote in it"} |
Well, CMUD doesn't use \. In fact, CMUD doesn't parse *anything* within " quotes...it treats that as a literal string. To include an embedded quote in CMUD, you "double" the quotes. In CMUD it needs to parse this:
| Code: |
| var = {key="value with "" quote in it"} |
So now I really need to have two different parsing modes: strict json, and CMUD-compatible. In CMUD-compatible mode, the \ inside the quotes would be ignored and doubled-quotes would be parsed properly. In strict json mode the \ would work as an escape character.
Still makes my head hurt. But I'm making progress. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
