Inserting Associative Elements

ID:2149873
 
Sep 19 2016, 6:13 pm (Edited on Sep 19 2016, 6:24 pm)
Code:
src.HotKeys.Insert(num,text)
src.HotKeys[text]=element


Problem description:
The above is my current solution but I would like to insert the association in one statement. Like...
src.HotKeys.Insert(num,text=element)
//or
src.HotKeys.Insert(num,list(text=element))




Also, how would one get an element of an associative list if he knew the position of the element but wanted to retrieve the element not its associative value without looping thru the list. For instances

var/list/HotKeys=list("A"="Punch","S"="Kick","D="Jump")
for(var/i=1,i<=HotKeys.len,i++)
    var/elem="The element I want to retrieve"
    world<<"You pushed [elem] to perform the action [HotKeys[i]]"





Sep 19 2016, 7:33 pm (Edited on Sep 19 2016, 7:47 pm)
I would like to insert the association in one statement. Like...

No such luck. Inserting an element at a specific position of a list and assigning an associated value are entirely different operations and there's no shortcut that I know of to assign them properly. If you are using an associative list, you should not be depending on order being consistent.

Also, how would one get an element of an associative list if he knew the position of the element but wanted to retrieve the element not its associative value without looping thru the list.

If you know the KEY of the element:

l[key] //gets value


If you know the position of the key:

l[pos] //gets key


If you know the position of the key and want the value:

l[l[pos]] //gets value


If you know the value you want to find, but want to find the key it is stored under:

//You probably shouldn't actually be using an associative list.


Associative lists are intended for quick lookups and storage of known unique key-value pairs. They do not need to be ordered in a particular sequence and you should not be depending on values being unique because that's not a pattern that they are good for.

Odds are that you are using the wrong approach if you need any of the behavior that they aren't good for, or you need to build a linked-list approach using multiple different kinds of list storage schemes to keep track of the desired function for different purposes related to the same associative list.


Lastly:

world<<"You pushed [elem] to perform the action [HotKeys[i]]"


You should never need to know what elem is, because at some point the player had to push a key to trigger the action. If at some point later on down the call chain you need to know what key is pressed, it's because you discarded a value you already knew. Pass it down the chain as an argument rather than searching for it.

So, basically, what you have going on in the example is a situation where:

client
    verb
        onKey(bind as text)
            mob.doAction(hotkeys[bind])

mob
    proc
        doAction(action)
            var/skill/s = skills[action]
            s.Used(src)

skill
    proc
        Used(mob/user)
            var/bind
            //shit, what button did I press to get here?
            for(var/v in user.client.hotkeys)
                if(user.client.hotkeys[v]==id)
                    bind = v //this could be wrong!
                    break


Vs what you ought to be doing:

client
    verb
        onKey(bind as text)
            mob.doAction(hotkeys[bind],bind)

mob
    proc
        doAction(action,bind)
            var/skill/s = skills[action]
            s.Used(src,bind)

skill
    proc
        Used(mob/user,bind)
            //all is right with the cosmos
Sep 19 2016, 11:54 pm
Although just for reference, associative lists do retain their key order, unlike hash tables in other languages where it's a crap shoot. They're internally stored as a regular list with a red-black binary tree attached.

To insert at a specific position and provide an associated value, the way to do it is to use Insert() first and then do the association.
Sep 20 2016, 12:53 am
Well, I was asking more for displaying onscreen hud rather than pressing keys. In particular, the Insert Associated List was being used for the ability to change macros on particular skills. usually a macro from 1-9 to possibly a macro with a letter. I thought it was weird that I wasn't receiving the key from Hotkey[num] but I guess the value was actually text like "1" which returned the associated value... Nonetheless I definitely appreciate you guys answering all my questions.
Sep 20 2016, 12:59 am
Well, I was asking more for displaying onscreen hud rather than pressing keys.

Okay, great. Yes. This is the wrong use of associative lists for that.

You should abstract the bind/id from the hud object.

You have X bind slots, so you can refer to them by position. The keybind bound to the hotslot should be aware of what number the keybind represents. Therefore you should be able to go from there.

Hotslot1 doesn't need to know what key is bound to hotslot1

Key needs to know what hotslot position it is bound to.

So long as you have an ordered list of your hotslot objects, you can easily get the hotslot object by number. The bind should reference that number, not the other way around.

Then abstract the skill in the hotslot from the hotslot itself. You can keep a separate list of hotslot_skills that you then reference by number.

That way the hotslot's graphics can be updated by grabbing the skill, and you don't have to actually move the slots themselves around back and forth.

It's usually best to keep your logical and visual information separate.