 |
| Arde |
Posted: Fri Mar 06, 2009 5:26 pm
[3.03a - 3.04a] %vartype |
|
Arde
Enchanter
Joined: 09 Sep 2007
Posts: 605
|
 Posted: Mon Mar 16, 2009 5:32 pm
|
| Rahab wrote: |
I think that the following:
| Code: |
#local $myvar
#call %vartype($myvar, 4)
#show %vartype($myvar) |
should print 4. |
I see "-1" output from an alias with your code.  - i.e. a) %vartype works only with common (non local) variables and b) their names must be hard-coded into the script |
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Mon Mar 16, 2009 6:24 pm
|
I never said that it does that now, I only said that's what it should do, IMHO. You were arguing it should do something else.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Mar 16, 2009 7:22 pm
|
Actually, the %vartype function only works with "normal" variables and not with local variables. It is very difficult to make this work with local variables since they reside on the internal runtime stack and %vartype is accessing variables stored in the database. Since local variables are not stored in the database, %vartype doesn't have access to their type information. I'll add it to the wish-list for the future, but it's not going to be a huge priority.
I suggest in the meantime that you use normal variables with the "Use Default" flag enabled. With this flag enabled, your changes to the variables are not saved to the database, which makes them faster than other normal variables. |
|
|
|
|
Arde
Enchanter
Joined: 09 Sep 2007
Posts: 605
|
Posted: Mon Mar 16, 2009 11:01 pm
|
| Zugg wrote: |
Actually, the %vartype function only works with "normal" variables and not with local variables. It is very difficult to make this work with local variables since they reside on the internal runtime stack and %vartype is accessing variables stored in the database. Since local variables are not stored in the database, %vartype doesn't have access to their type information. I'll add it to the wish-list for the future, but it's not going to be a huge priority.
I suggest in the meantime that you use normal variables with the "Use Default" flag enabled. With this flag enabled, your changes to the variables are not saved to the database, which makes them faster than other normal variables. |
Zugg, the problem is not with local variables and their types. The problem is that %vartype currently takes literal string type argument and it (the argument, i.e. normal variable name) must be hard-coded into the script; %vartype doesn't expand it's argument. Now, since %vartype can't access type information for local variables, can it check it's argument and, if 1) it is a local variable and 2) it is the only argument that've been supplied, expand it? Is it possible to add this tweak to the %vartype?
%vartype can't expand normal variables, but it could expand local variables, allowing an indirect referencing this way |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Mar 17, 2009 12:50 am
|
OK, I misunderstood this discussion then. If you are asking %vartype to expand it's argument, I can certainly do that. As it has already been mentioned, this will prevent %vartype from ever accessing the type of a local variable, but since that doesn't work right now anyway I guess I don't see a problem in doing this.
What I *can't* do is expand the argument but then not expand local variables. Once %vartype expands it's arguments, then %vartype($myvar) is going to return the type of whatever variable name is stored in $myvar.
The only other side effect of expanding the argument is that %vartype(@varname) is going to return the type of the variable named in @varname, rather than returning the type of the varname variable itself like it does now. But %vartype might be new enough that people aren't using this poor syntax yet. |
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Tue Mar 17, 2009 1:51 pm
|
Yes, Arde was arguing in favor of that change. I was arguing against it and in favor of the functionality I would prefer. But if typing local variables is as hard as you say, I guess I can accept Arde's added functionality versus no added functionality at all. 
|
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Wed Mar 18, 2009 8:44 am
|
I am in favor of it expanding and evaluating its parameters as well. However I would like to see it done in a consistent fashion for all things that use the varname type of parameter. This includes commands like #ADDITEM and #DELKEY, and function such as %pop and %vartype.
Currently $local is used both for naming and referencing local variables. Indirection generally isn't suggested, but it is becoming more common. My suggestion is to add an indirection character like ^. Examples of this would be:
#ADDITEM $local {abc}
#ADDKEY $local^ {def} {ghi}
$local=xyz
$local^=cute
jkl=test
$local=jkl
#SHOW @abc -- @xyz @{$local}
Would display
def=ghi -- cute test |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
 |
|
|
Arde
Enchanter
Joined: 09 Sep 2007
Posts: 605
|
Posted: Mon Jun 15, 2009 9:27 pm
|
I just think, may be it will be better to rename %vartype to %setvartype and add its counterpart %getvartype instead of tweaking 1 function for work with both "set" and "get"? I believe it will be easier for Zugg to maintain the code for 2 simple functions as well.
|
|
_________________
My personal bug|wish list:
-Wrong Priority when copy-paste setting
-1 prompt trigger for Mapper, Session and General Options, not 3 different!
-#SECTION can terminate threads
-Buttons can't start threads |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Jun 16, 2009 3:59 pm
|
No, this won't be done. CMUD has *many* functions that work as both a "set" and "get" kind of function. Just look at all of the %roomXXX functions.
|
|
|
|
|
|
|
|
