var / static

ID:132893
 
Aug 17 2009, 7:29 pm
If I define a static var high up in the type-tree (such as at atom or atom/movable) and then try to set a different variable for something lower in the type tree (such as /mob or /obj) the compiler gives me the error 're-initialization of global var'.

Shouldn't there be a different instance of the static var for each individual type, not just one static var for every single type?

If not... How could I define a variable that would be present across any subtypes of the type i define it on, defaults to the setting I placed on the primary type, and can be changed on any subtypes? Oh.. and can be accessed like a static var.

Example: /obj:MyVar, instead of creating a new obj and then checking the var.
I CAN work around the issue in the manner I just said, which is simply loop through all of the typesof() and create one new object for each and check the var (using a non static var)... But I'd really like to not if at all possible.
Aug 17 2009, 7:33 pm
Wait, when did we get static variables? Or is this just a hypothetical question?
Aug 17 2009, 7:36 pm
In response to DarkCampainger
DarkCampainger wrote:
Wait, when did we get static variables? Or is this just a hypothetical question?

LoL!
Yes we have static variables.

Stealing a snippit from a previous discussion...
obj/var/static/Test=1
obj/var/const/Test2=1
mob/var/static/MahTest=/obj
mob/verb/Test2()
    world<<MahTest:Test
    MahTest:Test=2
    world<<MahTest:Test
    world<<MahTest:Test2
    //MahTest:Test2=2

If you unquote that last line it will produce errors because you're trying to change a const. The rest operates appropriately.

(Someone had said that static was another word for const)


But I have to say they aren't "fully" functional, mostly because people don't seem to use them much... I like them though. :(
Aug 17 2009, 7:45 pm
In response to AJX
Aha, it confused me because it used the keyword static, but it isn't really static in the usual sense.

Apparently the static keyword is equivalent to the global keyword, which is why you're having this issue -- it isn't tied to the atom type at all.

That is, if I'm understanding this correctly. I don't use variable modifiers other than tmp very often..
Aug 17 2009, 7:50 pm
In response to DarkCampainger
I'm not sure on that. I can't test right now, could you?

If you define:
atom/var/static/PWN=1

And try to access it as
world<<PWN

does it work?


Anyway~ Meh. Sucks. I'm looking for static in the sense that it is a variable tied to the 'type' not to any one instance of said type.
Aug 17 2009, 7:55 pm
In response to AJX
Yep, outputs 1. But you defined it as an atom, which is a parent of /mob.

This shows that /obj/var/static/PWN and /mob/var/static/PWN are accessing the same variable:

mob/var/static/PWN=23
obj/var/static/PWN=1
mob/verb/Test99()
    world<<PWN
    var/type1=/obj
    var/type2=/mob
    world<<type1:PWN
    world<<type2:PWN

Outputs:

23
23
23
Aug 17 2009, 7:57 pm
In response to DarkCampainger
Thats odd..

The compiler gives errors if you try to define the same var on a subtype, but apparently even if it isn't a subtype or parent it uses the same var if it is the same name.

I don't believe that is intended.
Aug 18 2009, 1:18 pm
Static variables in DM are somewhat strange (note, however, that as Kaioken has drilled into everyone var/static is equivalent to var/global ;)).

var/a=10
client/verb/Test()
    var/T=/mytype
    var/mytype/instance=new()
    src<<"a: [a], [T:a], [instance.a]"
    src<<"b: [global:b], [T:b], [instance.b]"

mytype
    var/static
        a=11
        b=9000

Outputs:
a: 10, 10, 11
b: 9000, 9000, 9000


The fact that global:b worked shows that a global variable is created for every static variable. So if you try to declare two static variables with the same name, you'll get an error (or at least unexpected results) because BYOND is also trying to make two global variables with the same name.
Aug 18 2009, 1:50 pm
In response to DarkCampainger
DarkCampainger wrote:
Outputs:

23
23
23

It's still not the proper result you'd expect, but interestingly, I actually get 23,1,1 instead when running that code.

This shows that /obj/var/static/PWN and /mob/var/static/PWN are accessing the same variable:

Well, with further testing, they don't - however, it does show that method of accessing the 'special' global var can't differentiate between identically-named vars. It works fine if you use a more standard/conventional method.
There are 3 different methods to access such a 'special' global var: 
obj/var/global/NAM = "obj nam"
mob/var/global/NAM = "mob nam"

mob/verb
    Access1()   
        //method 1: access by var's defined type (obviously handled at compile-time)
        var/obj/O = 3 //assigned value doesn't matter, there doesn't need to be an object
        var/mob/M = 3
        src << "obj: [O.NAM] mob: [M.NAM]" //( : operator has same effect)
    
    Access2()
        //method 2: access by var name - essentially\
making the compiler guess and try to find the right var
        var/O = 2.3 //assigned value doesn't matter here, either
        var/M = "poo"
        src << "obj: [O:NAM] mob: [M:NAM]"
    Access3()
        //method 3: access by object reference and variable access
        var/mob/M = new
        var/obj/O = new
        src << "obj: [O.vars["NAM"]] mob: [M.vars["NAM"]]"

(Only method 2 can be used with proc/verb global vars.)
If you run that code, you'll see only method 1 can properly differentiate between the 2 global vars and output them both.

Anyway, what you used here: 
    var/type1=/obj
    var/type2=/mob
    world<<type1:PWN
    world<<type2:PWN

...is really method 2 above. As mentioned, the value those variables hold don't actually matter - they're not actually being read and used, contrary to what we believed previously. You can set them to any value you'd like and the result won't change; so this is why you can't use it to differentiate between identically-named vars - DM has no way of knowing which one to pick here, so it probably just grabs the first it found. This might even be done at compile-time like method 1 is.
Also, about this in your code: 
mob/var/static/PWN=23
mob/verb/Test99()
    world<<PWN

Someone might've missed that, so just making sure it's known the last line is of course just interpreted as src.PWN, and this corresponds to 'method 1' (yes, 1, not 3). Lastly, for completeness, the global:VAR syntax is essentially a different way of using method 2.

Anyway, in light of the above, with non-uniquely-named 'special global vars', looks like you should stick to using method 1, or you might accidentally catch a different global var with the same name, eh.
Aug 18 2009, 2:55 pm
In response to Nickr5
Ok:

How difficult would it be to implement a 'real' static effect?

Is it worth it?