 |
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
 Posted: Thu Nov 15, 2007 9:48 pm
Simple scoping question
|
I started a new thread to ask a couple very simple questions. I want to try to avoid getting a headache over this scoping stuff. So, here are the simple questions:
1) Imagine that you have a package that you are writing. In this package you have this:
| Code: |
#VAR Count 0
#ALIAS DoWork {ADD Count 1} |
Now, in the main MUD window, you also have a @Count variable. So the question is: When you type "DoWork" on the command line to execute the alias in your package, which variable *should* it increment? Should it increment the @Count in the MUD window, or should it increment @Count in the package?
2) OK, now expand upon this a bit. In the *package*, add the following trigger:
| Code: |
| #TRIGGER {do work} {DoWork} |
Now, in the MUD window, type #SHOW "do work". Now, which variable *should* it increment? |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Nov 15, 2007 9:50 pm
|
So, I'm going to give my own answers first. But please give me your answers still. Also, explain "why" if you can.
1) It should increment the @Count within the package. If @Count didn't exist in the package, then it should increment the variable in the window. But it should always look within the defining package first in case the package designer has already created the variable. If the variable already exists within the package, then scripts within that package should always use it.
2) It shouldn't matter whether an alias is run from the command line or from a trigger fired within the window. So it should be the same as (1) |
|
|
|
|
Rainchild
Wizard
Joined: 10 Oct 2000
Posts: 1551
Location: Australia
|
Posted: Thu Nov 15, 2007 10:16 pm
|
/agree with Zugg ... packages should be treated similar to "classes" in standard programming languages ... the variables/functions inside are used first over any external ones. If you didn't have "Count" defined in the package, then it would use a count from the "global" (MUD window) scope, if it is defined in the package it should use it from within the package scope, unless the global variable/function is explicitly requested.
|
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Thu Nov 15, 2007 10:42 pm
|
I would have to agree with that as well. The variable Count is in the package with the alias because the author of the package had a good reason to put the variable in that package. I don't think a set of rules no matter how complex will ever cover every circumstance. Once a package is published then its user can make changes for thier own design, but I do not think any rules within CMud should make changes in the authoring design.
|
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Nov 15, 2007 11:56 pm
|
| Quote: |
| The variable Count is in the package with the alias because the author of the package had a good reason to put the variable in that package. |
Exactly! And that's the key. This is something the package designer has complete control over. So they can decide whether to look at an instance variable in the window or to look at their own variable in the package. They don't have to worry about what the end-user might or might-not have defined.
So, we've got some basic agreement here. What's funny about this, is that this conclusion is exactly the reason why aliases were switching context in v2.10. So 2.11 screwed this up!
Actually, that isn't quite fair. When I went to implement this designed behavior again, I found that the method I used in v2.10 was not correct either. So it's been bugged the whole time. But I think I have it working properly in 2.12 again. I'll also post the results of the scoping test script over in the scope testing thread that JQuilici created. |
|
|
|
|
JQuilici
Adept
Joined: 21 Sep 2005
Posts: 250
Location: Austin, TX
|
Posted: Fri Nov 16, 2007 3:48 pm
|
As I mentioned in the scope testing thread, I agree with the above conclusions (after getting my head back on straight).
The same arguments apply to settings other than variables, too. Consider the following example:
| Code: |
#ALIAS nag($name) { tell $name Where's my money? }
#TRIGGER {Zugg} {nag Zugg}
#TRIGGER {Ichiro} {nag Ichiro}
|
I believe any author would be very surprised if the trigger suddenly started calling a 'nag' alias in the current window, rather than the one in the module where the trigger is located. |
|
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you! |
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Mon Nov 19, 2007 3:05 pm
|
The arguments above seem logical to me. I agree.
|
|
|
|
|
Zhiroc
Adept
Joined: 04 Feb 2005
Posts: 246
|
Posted: Mon Nov 19, 2007 8:40 pm
|
There's a third question to be asked:
3) Say Count does not exist in either the Window or the Package. Where should it be created?
My answer is: the window. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Nov 19, 2007 9:13 pm
|
Zhiroc: Well, almost. That is covered in some of the other scoping threads. I just asked a simple question here because I was trying to keep it simple and get some agreement on how it should work.
The problem with your statement is "Count does not exist in either the Window or the Package". What it should say is "Count does not exist anywhere in the search path". If Count doesn't exist anywhere in the search path, then YES, it is created in the Window. But if it exists somewhere else in the search path, then it just gets updated...a new variable doesn't get created. |
|
|
|
|
|
|
|
