mIRC Home    About    Download    Register    News    Help

Print Thread
Scope of %variables #75470 16/03/04 03:17 PM
Joined: Feb 2003
Posts: 2,650
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,650
In response to another thread, I would like to pose this suggestion to Khaled.

Presently, %variables set with /var have a scope that is limited to the confines of the alias that it was created in... and they cannot be seen by sub-aliases. I propose for sub-aliases to be allowed to see the parent's /var %variables as if they were global variables, and have the ability to modify them.

If they want to use a variable of the same name, they simply initialize it with the /var command as normal.

Here are some examples:

/alias-one {
  ; create a global variable
  set %somevar GLOBAL-ONE
  /alias-two
  ; the data from %somevar is "GLOBAL-TWO" because it was changed in /alias-two
  echo -a %somevar
}

/alias-two {
  ; change the value of the global variable
  %somevar = GLOBAL-TWO
  ; create a local variable that superceeds the global variable
  var %somevar = LOCAL-TWO
  /alias-three
  ; the data from %somevar is "HI ALIAS TWO", and will die when this alias ends,
  ; because it was initialized here with the /var command.
  echo -a %somevar
  return
}

/alias-three {
  ; display the data from %somevar. normally it would have displayed "GLOBAL-TWO"
  ; but since it existed in the parent alias, we will see "LOCAL-TWO".
  echo -a %somevar
  ; we can change its value too, and the alias will still be "local" and die in /alias-two.
  %somevar = "HI ALIAS TWO"
  ; now we create a variable of the same name, but it will be local to this alias only.
  var %somevar = LOCAL-THREE
  return
}

- Raccoon

Last edited by Raccoon; 16/03/04 03:37 PM.

Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Re: Scope of %variables #75471 16/03/04 05:05 PM
Joined: Dec 2002
Posts: 230
G
greeny Offline
Fjord artisan
Offline
Fjord artisan
G
Joined: Dec 2002
Posts: 230
I disagree. First, this would be very confusing. Second, it would break all of my scripts.

Re: Scope of %variables #75472 16/03/04 05:49 PM
Joined: Feb 2003
Posts: 2,650
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,650
I disagree.

First, it is an expansion off the existing relationship between global and local variables.

Give me a scenerio where it would break your scripts.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Re: Scope of %variables #75473 16/03/04 11:26 PM
Joined: Dec 2002
Posts: 31
N
Netchelandorious Offline
Ameglian cow
Offline
Ameglian cow
N
Joined: Dec 2002
Posts: 31
It would break my recursive aliases.

Re: Scope of %variables #75474 16/03/04 11:27 PM
Joined: Dec 2002
Posts: 2,962
S
starbucks_mafia Offline
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
As your example demonstrates, it would be impossible (or at the very least inconvenient) for an alias to retrieve global variables if a calling alias has a local variable of the same name. As greeny said, it could get very confusing. I don't know of a single computer language that does anything like this, the fact that there are God-only-knows how many hundred computer languages and none of them behave in such a way probably says something about the practicality of coding in such an environment.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Re: Scope of %variables #75475 16/03/04 11:48 PM
Joined: Dec 2002
Posts: 39
L
Larra Offline
Ameglian cow
Offline
Ameglian cow
L
Joined: Dec 2002
Posts: 39
You can use set -u %var value
This can do the trick of "static" variables also

while (...) {
/...
/some_alias
}

alias -l some_alias {
if (!%tmp_var) set -u %tmp_var 1
...
inc %tmp_var
}

Re: Scope of %variables #75476 18/03/04 01:20 AM
Joined: Feb 2003
Posts: 2,650
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,650
[color:006600]the fact that there are God-only-knows how many hundred computer languages and none of them behave in such a way probably says something about the practicality of coding in such an environment.[/color]

mIRC already behaves in this way, granting locally declared variables precidence over globally defined variables.

I pose that a calling alias should have the authority to define its sub-aliases's "global-variable-space". The benifits of doing this outweigh any cons, and there is an almost-zero chance of conflict in old scripts. [I can't think of any practical examples where it would break old scripts.]

If you want your sub-alias to have access to a similarly named global variable, then simply don't declare over it with the /var command. Put thought into the naming of your global variables, instead of preventing useful features from being added to mIRC.

Also, this would not break recursion.

- Raccoon


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Re: Scope of %variables #75477 18/03/04 01:55 PM
Joined: Dec 2002
Posts: 2,962
S
starbucks_mafia Offline
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Quote:
mIRC already behaves in this way, granting locally declared variables precedence over globally defined variables.

- That's really not the same thing as you're suggesting. Local variables are declared inside the alias, so the alias-writer knows exactly what possible variable-naming conflicts there might be and can adjust them accordingly, whereas someone calling an alias has no idea of what variables are being used inside it. Granted they could look, but the point is they shouldn't have to. To use a function a scripter should simply need to know the format of the input and output - not look through it's inner workings.

eg.
Code:
alias stats {
  echo -a You have loaded mIRC %loadtimes times
}

alias info {
  var %loadtimes = $getsysloadhistory
  echo -a System load times: %loadtimes
  stats
}

Suddenly the %loadtimes variable which is intended to be global in /stats will take on the values of the local variable of /info. If someone wanted to change the value of the %loadtimes variable simply for that single call to /stats they could just set the global variable and then reset it afterwards.


Spelling mistakes, grammatical errors, and stupid comments are intentional.