Extended dot notation (pick notation) proposal

Isiah Meadows isiahmeadows at gmail.com
Wed Sep 28 23:23:05 UTC 2016


On Wed, Sep 7, 2016, 04:10 Kris Siegel <krissiegel at gmail.com> wrote:

> > I'm just saying those references still exist, and ignoring them will
> lead you into more problems than this would solve.
>
> Not suggesting anything of the sort only that your workaround adds
> additional variables with possible object references and a more native
> implementation could work around that. Nothing more.
>
> > 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.
>
> Hmm this is interesting. It's been a while since I last memory profiled a
> web application but the last time if I kept any references to, say, DOM
> elements in any variables even if I was no longer using them they would
> still be eating up the memory causing memory leaks. Are you saying this is
> no longer the case? You don't need to necessarily get rid of all references
> to, say, a DOM element before the garbage collector will sweep it up?
>

If the DOM element is not live and either is not referenced, or referenced
only by things that are marked for collection, the GC will mark it
(assuming they are only referenced by it). Then after a while, it's swept
away with the rest of the garbage.

(Technically, this is an oversimplification, but it's a complex topic.
Also, this doesn't apply to really old IE, which uses reference counting
instead.)


> I'm more curious than anything else; it appears my understanding here
> might be wrong so I want to dig into it more.
>

You do, but extra syntax for `pick` makes 0 difference in this area. My
point is that the new references in between are created and retained
regardless of how you create them.


> > Oh, and I've already suggested another, more specific, `pick` syntax
>
> Good read. Interesting. Honestly I'm more of a fan of introducing
> functions if possible to handle much of this instead of new syntax though I
> don't know if that is necessarily supported by others and that proposal
> goes a bit before what I was originally thinking.
>

I agree, too. And for individual properties, it is helpful, but this
language isn't quite as functional as people want to think. Also, it's not
like the alternatives are much larger: `x => x.property` (and for the
original proposal's shorthand: `(...xs) => console.log(...xs)`).


> On Tue, Sep 6, 2016 at 8:54 PM, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
>
>> I'll note that the type checking part will eventually get fixed in
>> TypeScript, at least.
>>
>> https://github.com/Microsoft/TypeScript/issues/1295
>>
>> Oh, and I've already suggested another, more specific, `pick` syntax
>> (that operation is only a shorthand for `x => x.property`) ,but it
>> ultimately got rejected since no one could really agree to anything
>> different other than the current state was workable, but not optimal. You
>> may appreciate reading the entire conversation, as it's pretty informative
>> and is related to this.
>>
>> Here's the specific comment proposing that idea:
>> https://github.com/tc39/proposal-bind-operator/issues/24#issuecomment-141331472
>>
>> Here's the issue where most the related discussion took place:
>> https://github.com/tc39/proposal-bind-operator/issues/26
>>
>> On Tue, Sep 6, 2016, 13:07 Bob Myers <rtm at gol.com> wrote:
>>
>>> Here is a little decision tree of the issues.
>>>
>>> [image: Inline image 1]
>>>
>>> On Tue, Sep 6, 2016 at 6:49 PM, 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/20160928/6d03ad28/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 51547 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160928/6d03ad28/attachment.png>


More information about the es-discuss mailing list