#variablestore

1 messages · Page 1 of 1 (latest)

fathom sundial
#

.

#

If I have a left hand gameobject variable

#

And I need to do something with it from 2 different scripts, I can just access it from the variable store, mainly if I have multiple different scripts needing to access it I can just access the var from the variable store

#

Instead of referring to the first script that uses the left hand, or having multiple left hand variables

#

@woven lagoon

woven lagoon
#

Sounds like you just want the singleton pattern tbh

fathom sundial
#

what

woven lagoon
#

Or just a Dictionary<string, GameObject> which is kinda clunky but

fathom sundial
#

I dont want to only store gameobjects in it though

woven lagoon
#

You can make a Dictionary<string, object> but your code is going to be extremely ugly

fathom sundial
#

thats what Ive done

#

But to add to the dictionary it wants a string for the key and I want the key to be the same as the variable

empty smelt
#

So many casts and no ability to refactor

fathom sundial
#

what

woven lagoon
#

You're basically throwing away all compile time safety and any ability to understand what your code is doing.

empty smelt
#

can you stop just saying "what"

fathom sundial
#

idk wtf that means

woven lagoon
woven lagoon
#

the key is used to lookup the value

empty smelt
#

Elaborate

woven lagoon
#

wdym "store" it

#

all objects are stored in memory

#

as long as they exist

#

you don't need to "store" them elsewhere

fathom sundial
#

like have all the variables in one place

woven lagoon
#

one completely unmanageable place

fathom sundial
#

wdym

#

Just get the variable with the variables name

#

and add the variable the same way

woven lagoon
#

what if there's two objects with the same name

fathom sundial
#

then what are you doing

woven lagoon
#

having two objects?

fathom sundial
#

unless its like enemies or something

#

in that case

#

uh

#

damn

empty smelt
#

You don't even know what type is in the store, so every time you have to get it you need to perform a cast. If you ever refactor that code you have to find all the places where it's used by name and change the types you've casted, it's a nightmare

fathom sundial
#

ill probably add something to take care of that

fathom sundial
#

i figured the value would tell it what kind of variable it is

#

the dictionary value

woven lagoon
#

What's better?

void Awake() {
  GlobalObjectStore["LeftHand"] = this;
}
// elsewhere
GameObject leftHand = (Hand)GlobalObjectStore["LeftHand"];```
Or just:
```cs
public static Hand LeftHand;

void Awake() {
  LeftHand = this;
} 

// elsewhere
Hand leftHand = Hands.LeftHand;```
#

notice... we have type safety and compile safety in the bottom one

empty smelt
#

practically, if you ever find yourself using object outside of serialization, you've likely done something wrong.

fathom sundial
empty smelt
#

Also, wouldn't that be:

(Hand)GlobalObjectStore.Store["LeftHand"];
woven lagoon
#

yes

woven lagoon
#

and i'll have to investigate what happened

empty smelt
fathom sundial
#

I dont spell things wrong

woven lagoon
#

in the second example if I spell it wrong anywhere, the compiler will tell you instantly

fathom sundial
#

I dont

woven lagoon
#

Well if you never make mistakes, then sure

#

I've never met such a superhero before though

fathom sundial
#

I do make mistakes, just not spelling mistakes

woven lagoon
#

If you:

  • use the wrong type in the cast
  • use the wrong name
  • miscapitalize
    the compiler won't help you.

If you want to click on the variable name and see where it's defined, you can't do it with your approach at all. With the second approach, you can, and you get the handy "n references" in VS, etc...

#

there's just... so much more to help you along when you don't actively try to fight against the type system

fathom sundial
#

oh yea

#

so no way to do it?

woven lagoon
#

I just don't see any benefit you gain from doing it

fathom sundial
#

Only ever having to reference one script

empty smelt
#

If anyone else saw code like that they would be overcome with violence and a need to destroy

fathom sundial
#

lmao

woven lagoon
fathom sundial
#

ease of use

#

tidyness

woven lagoon
#

we have different definitions of those things I guess

fathom sundial
#

how would it not be nea

#

neat

#

everythings in one place

woven lagoon
#

one big unorganized pile

fathom sundial
#

true but just use .Sort or whatever

#

or the find thing

#

whatever

woven lagoon
#

And wait a century for everything to be sorted?

#

I don't even actually know what you mean by sorting this thing anyway lol

empty smelt
#

For no reason. Dictionaries are unsorted

fathom sundial
#

no im saying it wouldnt matter that its unorganized, just use the find thing

woven lagoon
#

Imagine if a hospital stored medical records, employment records, utility bills, contractor contracts etc all in the same file. Instead of saying patients["John"] you now try to do everything["John"]

#

but how do you know if you're going to get back a patient record

#

or an employee record

#

or a guy who installed the light bulbs?

fathom sundial
#

by not having two variables named the same thing

woven lagoon
#

SO now I do everything["Patient John"]

#

how is that any better than patients["John"]

fathom sundial
#

yea

#

because its in one place

woven lagoon
#

except that now I lose type safety

fathom sundial
#

so its neat

#

and you only have to reference everything instead of multiple different things

woven lagoon
#

This isn't the way man

#

but

#

try it

#

see how it works for you

#

maybe you'll love it

fathom sundial
#

well idk how to

#

do it properly

woven lagoon
#

Dictionary<string, object>

empty smelt
#

you're also allocating constantly

#

every time you set or access something you have to allocate a string

#

and that is a lot of garbage

woven lagoon
#

Not to mention yes a dictionary lookup is fast but still slower than direct references

#

it's also proportional to the length of the string key...

#

also who is responsible for putting objects into the giant dictionary?

#

And maybe more importantly

#

who is responsible for removing them?

#

How do you not end up with 1000 orphaned references to destroyed objects

fathom sundial
#

yea

#

maybe if ondestroy if the variable is null it removes it

empty smelt
#

Anyway, if you really do want to do this absolute travesty of an idea, my answer to how you would handle names would be something like this:

public void Set<T>(T obj, bool force = false) where T : UnityEngine.Object => Set(obj.name, obj, force);

public void Set(string key, object obj, bool force = false)
{
    if (!force)
    {
        if (_store.TryGetValue(key, out var other))
            throw new ArgumentException($"Key \"{key}\" already exists in the store, with the value \"{other}\".");
        _store.Add(key, obj);
    }
    else
    {
        _store[key] = obj;
    }
}```
Where UnityEngine.Object types names are automated, but for any other type you must specify a key. You could do the same thing for `Get`.
Again, this is awful for so many reasons though, probably even more than we've already mentioned
woven lagoon
#

Also the whole idea that this is somehow a store of "everything" in one place is false anyway

#

Whenever you spawn something at runtime, or have multiple of a single type of object (multiple enemies, projectiles, chunks, etc...) you can't use your system for it

fathom sundial
#

it stores variables

#

and youd need something to tell it what to spawn at runtime

woven lagoon
#

"variables" are not things that can be stored actually

#

objects and references are stored in variables