Rationale for dicts?
On Mon, Oct 17, 2011 at 12:54 AM, Axel Rauschmayer <axel at rauschma.de> wrote:
I do not yet fully understand the rationale behind dicts. I have two questions:
Why does it need to use the same mechanism for looking up keys as objects? Couldn’t methods be introduced for this? Then a dict could have other methods, too (even if they come from a wrapper type). For example, a size() method.
Why not allow any kind of key? Why restrict keys to strings? That seems arbitrary.
Allowing object keys would would be leaky -- if you want this use a WeakMap, that's what it's for, right?
But more important, even though typeof would be distinct, it'd still confuse any grizzled js vet to learn that dict[1] !== dict["1"]. IMHO the implicit toString behavior on property assignment is far too ingrained in the language to diverge from it now.
I do not yet fully understand the rationale behind dicts.
Nothing fancy, really. Just an idiomatic way to create a non-polluted string-to-value map. In ES5 you can use Object.create(null), which is not bad but still kind of a hack. Wouldn't it be nice to have sweet literal syntax for a dictionary that you know is not going to pull any any of the complexities of the object semantics?
My main issues with the proposal at this point are 1) the cost of new typeof types, and 2) the syntax doesn't work for the case of empty dictionaries.
- Why does it need to use the same mechanism for looking up keys as objects? Couldn’t methods be introduced for this? Then a dict could have other methods, too (even if they come from a wrapper type). For example, a size() method.
The point was for it not to be an object. A much flatter kind of data structure. You could think of it as formalizing the internal concept of an object's own-properties table.
- Why not allow any kind of key? Why restrict keys to strings? That seems arbitrary.
As I say, what inspired me to explore the idea was exposing the internal concept of an own-property table as a first-class data structure. It's just a simpler primitive to work with than an object.
We might want to allow name objects as keys too, to continue tracking the notion that a dictionary is a mapping from property names to values.
Got it. A primitive for string-to-value maps that exposes functionality that is already there.
But then it sticks out from all other primitives, which have wrapper types and, via them, methods that can be called.
If accessing dict entries had a different syntax that problem would go away:
dict@["k"+"ey"] = 123;
dict at key = 123;
console.log(dict at key);
And you could have methods, too: dict.size()
strawman:dicts
I do not yet fully understand the rationale behind dicts. I have two questions:
Why does it need to use the same mechanism for looking up keys as objects? Couldn’t methods be introduced for this? Then a dict could have other methods, too (even if they come from a wrapper type). For example, a size() method.
Why not allow any kind of key? Why restrict keys to strings? That seems arbitrary.
Axel