Elvis: They would be universally a bad idea if they leaked memory.

Seide: Is it safe to use objects as dictionaries if you create them with Object.createnull?

Seide: In the past, safe dictionary libraries would prefix all keys with a ‘$’ or something to prevent dangerous behavior with “__proto__”

Seide: ES6 maps are, AFAIK, slower than object dictionaries since the former has to deal with keys of all types, not just strings

Adami: Seide, use Maps if they are available and you want extra safety

Seide: But what are the dangers of using an object constructed with Object.createnull? And do they apply to the latest node v8 / Firefox / Edge?

Norman: Seide: accessing objects dynamically is going to be slower than using Map.

Dentino: Seide: VMs only optimise static access. And if you use objects as maps, they’re going to 1 deoptimise that object to a map anyway, after recompiling your code too many times because the hidden cl***es changed too much; 2 deoptimise all of the functions touched by those maps, because they’ll become megamorphic too many shapes going into them

Seide: Right, so the object will deoptimize to a map that *knows all keys are strings*

Mcguckin: Complexity wise, both operations are O1 though. And you shouldn’t care about the these things.

Seide: Whereas the ES6 Map is going to be a map that *can’t ***ume anything about its keys*

Valrey: Seide: that’s not how things work.

Letlow: Seide: a dynamic thing, by definition, can’t know all of its access paths, because the access paths aren’t defined. Ergo, it’s not possible to optimise it.

Fabry: Seide, just make sure you do not set fancy keys

Seide: But how is the Map going to be faster?

Glenny: I use objects as dictionaries a lot, without even making proto null

Pigat: Never got any issues from this

Stoyanoff: Seide: In both cases you get a hash lookup + disambiguation, which is algorithimically O1. But 1 Map is *more correct*, because it has been designed *EXACTLY FOR THIS USE CASE*. 2 Map is going to be faster, because changes in object propagate and *deoptimise EVERYTHING THEY TOUCH*

Seide: RLa: if I’m storing arbitrary data in the dictionary, I can’t ensure none of the keys are” __proto__”

Rapoport: Really arbitrary data?

Seide: Yeah, mapping strings to values, perhaps in a cache or whatever

Morimoto: That’s tough case then

Trauth: Seide: *EVEN* if objects were marginally faster they aren’t, it’s not worthy the potential correctness issues, because you won’t be seeing any *real* performance gains anyway.

Santelli: And likely: it doesn’t matter anyway. It’s not like you’re writing a tight loop for a game, because tight loops for games don’t use Maps.

Elvis: I agree with Hylle, but you could ensure none of the keys are “__proto__” by checking

Seide: Tcsc: what would I do if code tries to store something under the __proto__ key? Client code’s gonna expect to store data under any key, just like a sensible dictionary?

Elvis: Make an empty object, check if the key is in the empty object, add some special character before the key. also, add the special character in front of any keys that already start with it

Seide: Hylle: I’m still not understanding why a lookup in a string dictionary isn’t faster than a lookup in a Map. If I’m using the object as a dictionary, then I don’t care if the JS engine treats it “deoptimized” like a dictionary lookup. Cuz that’s exactly what it is

Seide: Tcsc: right, that’s what “safe” dictionary libraries do: they prefix every single key with a prefix

Taque: Seide: did you read everything I said up above?

Elvis: Deopt refers to the code around the lookup, more than to the lookup

Elvis: But, Map is what you want.

Seide: Tcsc: ok, makes sense, if the rest of the function gets deoptimized

Elvis: Its not guaranteed but it can definitely happen

Elvis: You’d have to look at the profiler or run chrome with special flags to be certain.