 |
worlo
Newbie
Joined: 20 Jul 2004
Posts: 8
|
 Posted: Thu Aug 05, 2004 12:42 pm
Variable assignment
|
Ok I am wondering is there a problem assigning variables that are in another class without using the full path to them?
example:
#class {someclass}
#trigger {*} {amok=1}
#class {0}
#class {othersomeclass}
#var amok {}
#class {0}
If this doesn't cause problems that would mean I can move around the "othersomeclass" without affecting the brilliant "*" trigger right? Why do so many people use @othersomeclass/amok to assign variables? Is there a reason other than keeping track of where your variables are? |
|
|
|
|
Rorso
Wizard
Joined: 14 Oct 2000
Posts: 1368
|
Posted: Thu Aug 05, 2004 12:59 pm Re: Variable assignment
|
| worlo wrote: |
Ok I am wondering is there a problem assigning variables that are in another class without using the full path to them?
example:
#class {someclass}
#trigger {*} {amok=1}
#class {0}
#class {othersomeclass}
#var amok {}
#class {0}
If this doesn't cause problems that would mean I can move around the "othersomeclass" without affecting the brilliant "*" trigger right? Why do so many people use @othersomeclass/amok to assign variables? Is there a reason other than keeping track of where your variables are? |
If you use a class as "set as default when executing", and you call an alias in another class you might get strange behaviour.
Example: Class1 which is a default class calls Class2 which creates a variable containing some information needed in other classes. In this case the variable would be created in Class1 as that was the default class calling Class2. Other aliases/classes that expects the variable to be in the root of the class hierarchy won't find the data they look for.
If classes don't use "set as default when executing" you can get issues if there are duplicate variable names. Like you have "movement" defined in many different classes. Which one should be shown if you ran #show @movement?  |
|
|
|
|
|
|
|
