 |
JQuilici
Adept
Joined: 21 Sep 2005
Posts: 250
Location: Austin, TX
|
 Posted: Tue Nov 13, 2007 7:55 pm
[2.11] Identical class name masks settings, even with different names
|
Summary
If two classes in different modules have the same name, settings inside one of them may be unavailable when referenced using the class name (e.g. @class/var). It appears as if the system finds the first instance of the named class and checks if the named variable is inside of it. If not, it gives up, rather than continuing to search for another class with the same name, which might contain the setting.
Procedure
- Start CMUD
- Press Esc to dismiss the sessions window
- Enter the following at the command line and hit Enter:
| Code: |
| #module mod1;#class //mod1/interface;#var foo foo;#class 0;#module mod2;#class //mod2/interface;#var bar bar;#class 0;#module 0;#show no class @foo @bar;#show with class @interface/foo @interface/bar |
On my system, this produces:
| Code: |
no class foo bar
with class bar |
Note that foo is invisible when referenced using the class name.
Notes
It is necessary to use the module name in the #class commands in the procedure (e.g. #class //mod2/interface). If you just do '#class interface', then both 'foo' and 'bar' will wind up in //mod1/interface. In other words, '#class foo' may set the current class to a class 'foo' in a competely different module (or even package? don't know), if such a class exists. I haven't decided if it's a bug, but it's worth noting (because it surprised me). |
|
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you! |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Nov 13, 2007 9:19 pm
|
This is correct behavior. I've mentioned it before, but basically, when CMUD doesn't find the setting within the current module, then it looks in other modules and the order in which it looks in other modules is undefined.
Hmm...actually, you are right. While the order is undefined, it should have still found the foo variable in the mod1 module. OK, I'll add this to the bug list to look at.
The issue of needing the module name in the #class command is correct. When you say "#class interface" it first looks for an existing class. So the first time there isn't an existing class, so it properly creates //mod1/interface. But when you are within the mod2 module and use "#class interface" it properly finds the existing "interface" class in mod1, so it sets that as the current module/class. This is exactly how it is supposed to work. When using unreferenced settings, it will always perform a search for an existing setting before creating a new one (just like with #variables). |
|
|
|
|
JQuilici
Adept
Joined: 21 Sep 2005
Posts: 250
Location: Austin, TX
|
Posted: Tue Nov 13, 2007 9:37 pm
|
| Zugg wrote: |
This is correct behavior. I've mentioned it before, but basically, when CMUD doesn't find the setting within the current module, then it looks in other modules and the order in which it looks in other modules is undefined.
Hmm...actually, you are right. While the order is undefined, it should have still found the foo variable in the mod1 module. OK, I'll add this to the bug list to look at. |
I was of two minds about this one myself, until Fang prompted me to post it.
| Quote: |
| The issue of needing the module name in the #class command is correct. When you say "#class interface" it first looks for an existing class. So the first time there isn't an existing class, so it properly creates //mod1/interface. But when you are within the mod2 module and use "#class interface" it properly finds the existing "interface" class in mod1, so it sets that as the current module/class. This is exactly how it is supposed to work. When using unreferenced settings, it will always perform a search for an existing setting before creating a new one (just like with #variables). |
Pretty much the explanation I expected. But thanks for the confirmation. The result is that those of us who like to be Careful Programmers will always use fully-qualified class names in #class statements, since you can never tell what names might show up at runtime. |
|
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you! |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Nov 14, 2007 12:00 am
|
| Quote: |
| The result is that those of us who like to be Careful Programmers will always use fully-qualified class names in #class statements, since you can never tell what names might show up at runtime |
No, actually I would still avoid using fully qualified names. Because then the name of your package is scattered throughout your scripts. Just use *unique* class names within your package and then you won't have this problem (and it fixes all sorts of other issues to). It's very easy to come up with your own naming scheme to ensure that your class names are unique. Or at least to make them something that someone else isn't going to use accidentally. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
