Darien Valentine (2017-08-11T06:25:02.000Z)
@Alexander The idea of a generalized `map` function (etc, I’m guessing) is
appealing. From the way you talked about it, it sounds like there may have
been
past discussion on the topic. Are there any proposals for this or major
ideas
being batted around?

> Why? What's the advantage? You lose at least the square bracket and dot
> notations for access, as disadvantages, and I'm not aware of any
advantages.
> If there aren't any that compensate for the disadvantages, then it's a net
> negative

@Naveen — a handful of things. Objects are indeed a perfectly reasonable
choice
for modeling kvp collections a lot of the time. On the other hand, because
objects in ES serve double duty as ways to model data and ways to "model
code",
they are not always ideal for the former case on account of the features
that
exist mainly to serve the second. Some examples of things that make maps
useful:
inherently iterable; no prototype chain access lookup; no collision with
`Object.prototype` property name when hashing by arbitrary keys; potentially
more efficient for situations where keys are frequently removed;
`map.has()` is
more straightforward than having to consider whether you want `key in` or
`Object.hasOwnProperty` or which properties have been defined as enumerable
or
not; iteration order of entries is 1:1 with insertion order; and of course,
keys
can be of any type. Further, maps can be subclassed to constrain the types
that
they may hold or add other behaviors without needing to define custom
Proxies.

Some general use cases: registries; hashing data where keys are from
external
input; kvp collections which are ordered; kvp collections which will be
subject
to later transformations; kvp collections to which new keys are frequently
added
or removed.

While I hope that information is somewhat helpful, there are probably much
more
detailed resources online (including, I suspect, past discussions on this
list)
which could explain some of those things better or which include cases I
haven’t
thought of.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170811/11b8c48c/attachment.html>
valentinium at gmail.com (2017-08-11T06:25:32.918Z)
@Alexander The idea of a generalized `map` function (etc, I’m guessing) is
appealing. From the way you talked about it, it sounds like there may have
been
past discussion on the topic. Are there any proposals for this or major
ideas
being batted around?

> Why? What's the advantage? You lose at least the square bracket and dot
> notations for access, as disadvantages, and I'm not aware of any advantages.
> If there aren't any that compensate for the disadvantages, then it's a net
> negative

@Naveen — a handful of things. Objects are indeed a perfectly reasonable
choice
for modeling kvp collections a lot of the time. On the other hand, because
objects in ES serve double duty as ways to model data and ways to "model
code",
they are not always ideal for the former case on account of the features
that
exist mainly to serve the second. Some examples of things that make maps
useful:
inherently iterable; no prototype chain access lookup; no collision with
`Object.prototype` property name when hashing by arbitrary keys; potentially
more efficient for situations where keys are frequently removed;
`map.has()` is
more straightforward than having to consider whether you want `key in` or
`Object.hasOwnProperty` or which properties have been defined as enumerable
or
not; iteration order of entries is 1:1 with insertion order; and of course,
keys
can be of any type. Further, maps can be subclassed to constrain the types
that
they may hold or add other behaviors without needing to define custom
Proxies.

Some general use cases: registries; hashing data where keys are from
external
input; kvp collections which are ordered; kvp collections which will be
subject
to later transformations; kvp collections to which new keys are frequently
added
or removed.

While I hope that information is somewhat helpful, there are probably much
more
detailed resources online (including, I suspect, past discussions on this
list)
which could explain some of those things better or which include cases I
haven’t
thought of.