![]() Sep 17 2010, 9:18 pm
In response to Forum_account
|
|
That's kind of the point I was trying to make :).
|
Lummox JR wrote:
Lummox JR Looks like we need to teach you a thing or two about redundancy, sir. |
It's actually not a function of the : operator at all, and using it with the : operator in a traditional manner is non-robust.
I've covered this in the past. static vars in DM are the same as global. Being able to access a global var without having an object is thus nothing special, since the global var is independent of any object. It's all pulled off at compile-time by the compiler doing a trick (or shortcut): when you access an object var with a name that ends up corresponding to a global object var's name, the result on compilation is simply an instruction to access that global var directly. Nothing with the object is done - the left-hand side of the . or : operator is virtually nonexistent in this case, so nothing is done with the variable at runtime, either. Therefore, the var's value doesn't matter, which is why you can use A:VarName without getting a type mismatch runtime error when A contains a non-object (such as a type path). mob/verb/testvar() The above is functional. However, since S has no defined type, no identification is given in regards to the global var wanted, so the compiler simply uses the first one found. Ergo, Bdatum.GVAR is inaccessible with this non-robust and inflexible method. Note that with this method you don't even require a var at all: mob/verb/testvar() As one would guess from the above, you can be more specific and robust by using a var with a defined object type that singles-out which var you want: mob/verb/testvar() Something actually special that you can do with the object var-accessing operators ('.',':') is access procedure properties from their type paths, as demonstrated in this post[link](yeah, the first parts of that post ended up quite silly). But this is only because the procedure type path is a special, unique datatype. In all of the examples discussed within this post, whether you use the . or : operator makes no functional difference - at all. The only difference you'll notice is that using the . operator is less error-prone, or alternatively: it simply has more conditions to compile successfully. |