Extended dot notation (pick notation) proposal

Isiah Meadows isiahmeadows at gmail.com
Thu Sep 29 01:15:48 UTC 2016


I'm just saying those references still exist, and ignoring them will lead
you into more problems than this would solve. First, my above workaround
would likely be the desugaring in V8. You *could* optimize it by creating
the actual object and assigning the properties as they come from the
object, but that's also a valid optimization for engines to make today with
my workaround. Also, most other optimizations are equally permissible with
both syntax and my equivalent workaround.

And this isn't C: unless you're using those references, JS engines will
clean them up automatically, anyways, because of their garbage collection.
My workaround produces 0 more required object references than what the
engine needs.

As you can see, I'm generally against this.

On Tue, Sep 6, 2016, 10:09 Kris Siegel <krissiegel at gmail.com> wrote:

> Internal is fine as someone from, say, the V8 team can clean up the
> references. Making the developer do it? In my experience good luck 🙂.
> Naturally it won't likely matter much unless it's hanging onto a DOM
> element or some extent resource but still.
>
> On Sep 6, 2016 6:19 AM, "Isiah Meadows" <isiahmeadows at gmail.com> wrote:
>
>> > Isiah's workaround works but has the unfortunate side affect of copying
>> values / increasing reference counts to objects. I'd love to see a built in
>> solution.
>>
>> You'd have to do that anyways, even if it's entirely internal. How do you
>> think you would do it outside of copying the values?
>>
>> On Mon, Sep 5, 2016, 19:45 Kris Siegel <krissiegel at gmail.com> wrote:
>>
>>> Hmm I gotta say I must have re-read that minimally extended dot notation
>>> proposal a few times and I just find the syntax confusing. I do like the
>>> idea of building a way of taking a portion of an object out of one object
>>> and into another but I don't think we need to provide additional syntax
>>> rules to handle this. Why couldn't this be an Object.pick() addition where
>>> it works similar to the underscore implementation? It could even be
>>> expanded to handle deep nesting (I'm actually adding this to my msngr.js
>>> library in the next release as grabbing a subset of an object is crazy
>>> useful and I need to do it far too frequently).
>>>
>>> Isiah's workaround works but has the unfortunate side affect of copying
>>> values / increasing reference counts to objects. I'd love to see a built in
>>> solution.
>>>
>>> On Mon, Sep 5, 2016 at 2:38 PM, Isiah Meadows <isiahmeadows at gmail.com>
>>> wrote:
>>>
>>>> TypeScript has a fair number of proposals aiming to address this
>>>> (things like difference types, partial types, etc.), but in general, I find
>>>> it just as easy to do it this way (which is easily checked):
>>>>
>>>> ```js
>>>> const {toDate, fromDate, location, flavor} = this.state;
>>>> const goodKeys = {toDate, fromDate, location, flavor};
>>>> ```
>>>>
>>>> On Fri, Sep 2, 2016, 16:08 Bob Myers <rtm at gol.com> wrote:
>>>>
>>>>> Here's another StackOverflow question
>>>>> <http://stackoverflow.com/questions/39299046/destructuring-a-subset-of-an-object-directly-into-a-new-object>
>>>>> essentially asking for pick notation. This same question pops up regularly.
>>>>> It's the real world talking to us telling us what they need. In this
>>>>> particular case, the solution with extended dot notation would just be
>>>>>
>>>>> ```
>>>>> var goodKeys = this.state.{toDate, fromDate, location, flavor};
>>>>> ```
>>>>>
>>>>> Perhaps I have not posted the minimal version of my proposal for this
>>>>> pick notation
>>>>> <https://github.com/rtm/js-pick-notation/blob/master/minimal/spec.md>,
>>>>> also known as extended dot notation.
>>>>> This version sacrifices some features in favor of complete
>>>>> compatibility with existing destructuring syntax following the dot.
>>>>>
>>>>> There is another good reason these days for thinking about something
>>>>> about this: *the advent of typed dialects of JS*.
>>>>> We already know that a simple lodash-type version of pick, such as
>>>>>
>>>>> ```
>>>>> function pick(o, keys) {
>>>>>   return Object.assign({}, ...keys.map(key => ({[key]: o[key]})));
>>>>> }
>>>>>
>>>>> const o = {a:1, b: 2};
>>>>> const o2 = pick(o, ['a']);
>>>>> ```
>>>>>
>>>>> cannot handle renaming or defaults or deep picking, but in addition *it
>>>>> cannot also not be typed properly*.
>>>>> For instance, `lodash.d.ts` defines `pick` as:
>>>>>
>>>>> ```
>>>>> pick<TResult extends {}, T extends {}>(
>>>>>   object: T,
>>>>>   ...predicate: (StringRepresentable|StringRepresentable[])[]
>>>>> ): TResult;
>>>>> ```
>>>>>
>>>>> with no type safety whatsoever.
>>>>>
>>>>> In contrast, with pick notation
>>>>>
>>>>> ```
>>>>> const o2 = o.{a};
>>>>> ```
>>>>>
>>>>> `o2` can be precisely typed by the compiler as an object containing
>>>>> the property `a`, or a type compatible or assignable to that type.
>>>>>
>>>>> --
>>>>> Bob
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160929/3124e2b6/attachment.html>


More information about the es-discuss mailing list