 |
GeneralStonewall
Magician
Joined: 02 Feb 2004
Posts: 364
Location: USA
|
 Posted: Mon Jun 28, 2010 7:39 am
[3.21+] Suggestion: Expanded string lists & databases
|
In previous versions of cmud, there was a bug where database and string list variables would return expanded. I had actually written a few scripts that relied on this and, with the new version, I was forced to make a few changes. What I would like to see is the option to have string lists and database variables be automatically expanded like expanded strings are. My preferred solution would be a simple toggle option, via the settings editor, that would set a flag for the variable.
Perhaps this could also be applied to literal strings, with the separate expanded type being removed. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Jun 29, 2010 4:45 pm
|
I am confused by exactly what you are asking for. Can you give some examples?
Expansion of variables within a string happens at parser time when the value is being stored to the database. You can still expand variables with lists and db records using the traditional CMUD string syntax, like this:
| Code: |
a = 123
list = {item1|@a|item2} |
and you will end up with the list "item1|123|item2" just as expected.
So are you talking about "expanded" in the same sense as expanding variables like the example above, which seems to already work, or are you talking about something else? |
|
|
|
|
GeneralStonewall
Magician
Joined: 02 Feb 2004
Posts: 364
Location: USA
|
Posted: Tue Jun 29, 2010 8:27 pm
|
I'm talking about having functions and references to variables stored within the database or string list, not their values.
| Code: |
#var testvar %null
#var testlist %null
testvar = "two"
#additem testlist "one"
#additem testlist "@testvar"
#additem testlist "%eval(1+2)"
#forall @testlist {
#print %i
} |
This is how it works now:
| Quote: |
one
@testvar
%eval(1+2) |
And this would be the proposed behavior with the flag:
The 2nd way is how it worked in previous versions of cmud, without needing to use %expand. That is, they worked like the expanded string type does. While it was a bug, it was something that I used; Adding %expand to every instance of a variable, if I decided to put a function or variable inside of it, would be a pain. If there are expanded strings, then it makes sense, to me, to have expanded databases and lists, too. So, that's why I'm requesting it as a feature.
Edit: Tried to make it a bit more clear. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Jun 29, 2010 11:07 pm
|
Why can't you just do this:
| Code: |
#var testvar %null
#var testlist %null
testvar = "two"
#additem testlist "one"
#additem testlist @testvar
#additem testlist %eval(1+2)
#forall @testlist {
#print %i
} |
That gives the results you are talking about. There isn't anything special about expanded strings. As I said, the expansion happens during the *assignment* of the value to the variable, just like in the above #additem case. You were getting literal strings because you had " quotes around each value. Just remove the " quotes and then CMUD will expand or evaluate the value just like when assigning to a normal expanded string variable. |
|
|
|
|
GeneralStonewall
Magician
Joined: 02 Feb 2004
Posts: 364
Location: USA
|
Posted: Wed Jun 30, 2010 12:18 am
|
I don't want the expansion to happen when I assign the variable; I want it to happen every time I reference it. I can do this with expanded strings, already. So yes, expanded strings -are- special in this case.
Like this:
| Code: |
testvar = {"%random(5)"}
#10 {#print @testvar} |
output:
| Quote: |
1
5
3
3
5
3
3
1
3
0 |
That is the type of behavior I want to have available for lists and tables, without sticking %expands everywhere. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Jun 30, 2010 4:13 pm
|
Nope, you need to do that with %eval then. There is no way to store "compiled code" in a json table variable, so you just need to store string values and then evaluate them at runtime using %eval. That's exactly what %eval is for.
|
|
|
|
|
GeneralStonewall
Magician
Joined: 02 Feb 2004
Posts: 364
Location: USA
|
Posted: Wed Jun 30, 2010 6:17 pm
|
So what's the difference between doing this with an expanded string variable and a table variable? I realize it would still have to be stored as a string value; I just figured there could be some way to set the variable to be expanded at runtime, without explicitly using %eval or %expand. I don't quite see how this would be different than my -working- example above; Isn't it just a string value as well?
I do appreciate the feedback, btw. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Jun 30, 2010 10:20 pm
|
It's not really "expanded string variables" that are working that way, even though it looks like it.
What is happening with your code:
| Code: |
testvar = {"%random(5)"}
#10 {#print @testvar} |
is that you are actually triggering some old compatibility code for user-defined functions. Back before the #VARFUNC syntax was added to properly define user-defined inline functions, back in zMUD you could do this:
| Code: |
#VAR myfunc "%random(5)"
#10 {#show @myfunc} |
Now, obviously that was a complete mess because it interfered with the ability to make a literal string variable. In CMUD, the " quotes are properly treated as literal strings and the #VARFUNC command was used to define inline functions, but using the {"%random(5)"} syntax with both the { and " quotes ends up defining the string variable like an inline function.
Internally, CMUD is just implementing this by calling %eval on the string result, so it's really no magic trick. And it's not something I'm going to add to tables. It would just mess them up. The fact that your above {"random(5)"} syntax works at all should be considered a side-effect of something that could go away at any time. |
|
|
|
|
GeneralStonewall
Magician
Joined: 02 Feb 2004
Posts: 364
Location: USA
|
Posted: Wed Jun 30, 2010 10:31 pm
|
Ah, ok. Thanks for explaining it fully for me. I guess what I was really asking for were varfuncs in table/list format? I just thought that having a way to automatically evaluate the 'string results' through a var option would be useful. It does seem like it'd be a fairly obscure thing to use, though.
Btw, looks like #varfunc isn't working correctly in some cases (the example one). I'll write up a new thread. |
|
|
|
|
|
|
|
