Rationale for Dict?
To partially answer:
You can use 'proto' because a dict is basically Object.create(null), which in ES6 means proto will be just another property. The dict module also exports entries, keys, and values, so the iteration protocol for a dict requires using one of those. An example of using dict:
import { dict, entries } from '@dict';
const myDict = dict({ a: 10, b: 20, c: 30 });
for (let [key, value] of entries(myDict)){
console.log(key, value);
}
In addition to Brandon's points, it seems to me a clear win from the "say what you mean" angle.
As to the justification, I would say it's beneficial to use a dict when you have string keys and you want to be able to use dot property access. Constantly having to use map.get(key) and map.set(key, value) is overly verbose if you're using string keys.
On Jan 8, 2013, at 21:24 , Domenic Denicola <domenic at domenicdenicola.com> wrote:
In addition to Brandon's points, it seems to me a clear win from the "say what you mean" angle.
That’s a good point. And proto being just another property helps tremendously.
However, not having methods seems unfortunate. It would be nice for Dicts to look like Maps with only string keys, but with get(), set() and has() being optimized under the hood. But maybe that’s too much effort.
Axel
More likely, knowing our friendly neighborhood JIT-coders, Maps which only contain string keys will be optimized under the hood.
The motivation for the @dict module is also better understood with a bit of context. Until recently, entries, keys, and values lived in '@iter'. They work on any object, creating an iterator from its properties. Recently the three were moved to '@dict' along with @dict.dict being added. In @iter is now zip and unzip which I haven't seen a description for, but I have a guess at their intended functionality and have roughed it in here Benvie/continuum/blob/gh-pages/engine/builtins/%40iter.js#L18 .
On Tue, Jan 8, 2013 at 4:01 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
However, not having methods seems unfortunate. It would be nice for Dicts to look like Maps with only string keys, but with get(), set() and has() being optimized under the hood. But maybe that’s too much effort.
It seems like doing type specialization for maps that only have string keys (as well as SMI keys) will be a huge perf gain for engines. We just need to write a performance test to force their hands.
-- erik
Right. Even better.
Playing devil’s advocate: Is Dict really necessary? Whenever performance doesn’t matter (as much), I’d advocate Map. Otherwise, I’d expect programmers who want the extra speed to be comfortable with Object.create(null).
Assumptions about Dict:
How will it implement the iteration protocol?