JS doesn't have interfaces (yet, tho there's a proposal) and regardless,
the "interface" for "iterable" is "it has Symbol.iterator, nothing more".
The only place a method like this - that produces an object - could
possibly exist, is a static method on Object.
I've already outlined two existing methods to copy one object's entries to
another; the only new functionality would be "creating an object from
entries", hence Object.fromEntries or similar.
I still haven't seen any use cases that aren't covered by the existing
"copy one object to another", or by a possible "entries to object" - does
anyone have any?
On Wed, Aug 9, 2017 at 12:56 AM, Naveen Chawla <naveen.c...@gmail.com>
> But I accept that this a very tall order for ES
> On Wed, 9 Aug 2017 at 13:22 Naveen Chawla <naveen.c...@gmail.com> wrote:
>> Java has a great example of such a construct: default interface methods
>> On Wed, 9 Aug 2017 at 13:21 Naveen Chawla <naveen.c...@gmail.com> wrote:
>>> The `toObject` behaviour doesn't need to be "implemented" on a
>>> per-iterable class basis. It has a constant behaviour: iterate and on each
>>> next(), pass the value to the `toKeyFromElement` and `toValueFromElement`
>>> callbacks to generate and return an object. There must be some construct by
>>> which that can be achieved. I wouldn't call it "better" to put it on Object
>>> (for the reasons stated), but rather a compromise in the absence of any
>>> such construct
>>> On Wed, 9 Aug 2017 at 13:12 T.J. Crowder <tj.crowder@farsightsoftware.
>>> com> wrote:
>>>> On Wed, Aug 9, 2017 at 8:35 AM, Naveen Chawla <naveen.c...@gmail.com>
>>>> > It would be in the `iteratable` `protocol` (interface)
>>>> As Jordan said, that's likely to be a nonstarter. The Iterable protocol
>>>> is *very* lean (exactly one required property) for a reason: So it can be
>>>> supported with minimum investment. Much better, IMHO, to put functions on
>>>> `Object` and `Map` (which is why that's what I suggested).
>>>> -- T.J. Crowder
es-discuss mailing list