Array.prototype.toObjectByProperty( element=>element.property )

[Jordan Harband]

I think you're misunderstanding; the function would of course take an
iterable. However, an iterable of what?

If it's an iterable of objects, then what's the key and what's the value?
What if it's an iterable of strings?

The only thing that makes sense is if it's an iterable that provides both a
key and a value - and "entries" is the idiomatic structure in the language
to respect a list of key/value pairs (besides "an object", of course).

What would you suggest?

On Wed, Aug 9, 2017 at 1:08 AM, Naveen Chawla <naveen.chwl at gmail.com> wrote:

> It is more generic than `fromEntries`
>
> On Wed, 9 Aug 2017 at 13:32 Naveen Chawla <naveen.chwl at gmail.com> wrote:
>
>> Iterable to object via `Object.fromIterable`
>>
>> On Wed, 9 Aug 2017 at 13:31 Jordan Harband <ljharb at gmail.com> wrote:
>>
>>> 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.chwl at gmail.com>
>>> wrote:
>>>
>>>> But I accept that this a very tall order for ES
>>>>
>>>> On Wed, 9 Aug 2017 at 13:22 Naveen Chawla <naveen.chwl at 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.chwl at 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 at farsightsoftware.com> wrote:
>>>>>>
>>>>>>> On Wed, Aug 9, 2017 at 8:35 AM, Naveen Chawla <naveen.chwl at gmail.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > 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
>>>>>>>
>>>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170809/f9ad4308/attachment-0001.html>