Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Towards Stage 4 #11

Open
3 of 17 tasks
hemanth opened this issue Jul 23, 2022 · 9 comments
Open
3 of 17 tasks

Towards Stage 4 #11

hemanth opened this issue Jul 23, 2022 · 9 comments

Comments

@hemanth
Copy link
Member

hemanth commented Jul 23, 2022

Below is the checklist, we can use this issue to discuss any questions that arise during each of these stage.

Stage 4

  • committee approval
  • implement in two browsers
  • significant in-the-field experience
  • merge test262 tests
  • write test262 tests
  • prepare ecma262 PR
  • editor-approved ecma262 PR

Stage 3

  • committee approval
  • spec editor signoff
  • spec reviewer signoff
  • received developer/implementor feedback

Stage 2

  • committee approval
  • spec text written
  • spec reviewers selected

Stage 1

  • introduced to TC39 [Presented by @hemanth in the 91st meeting]
  • champion(s) identified
  • initial explainer
@hemanth hemanth changed the title Towards stage-4 Towards Stage 4 Jul 23, 2022
@jonkoops
Copy link

What is the spec currently stuck on? Anything that could be done to help?

@ljharb
Copy link
Member

ljharb commented Jan 11, 2024

@jonkoops a champion (which atm is just @js-choi) would need to ask for stage 2, with a mostly complete spec, and would need to address anything that had been brought up at the stage 1 presentation (https://github.com/tc39/notes/blob/62238d83c4701b5805412f3cb059f2c2d1c164a9/meetings/2022-07/jul-21.md?plain=1#L561) or in the issues.

@jonkoops
Copy link

Thanks @ljharb. So I guess there isn't very much that can be done right now. @js-choi do let me know if I can assist you in pushing this forward.

@aleen42
Copy link
Collaborator

aleen42 commented Jan 16, 2024

I have reviewed the process of asking for stage 1 and found that the committee has discussed using syntax or defining strongly named arguments to a method. They both have reason to exist because the syntax is just like sugar for developers. In such a case, I would prefer to use strongly named arguments:

// _.fn is something like `Function.prototype.bind`, whose passed arguments `_` means the value passed by `Array.prototype.map`
data.map(_.fn(Object.pick, _, ['foo', 'bar']);

// same as
data.map(v => Object.pick(v, ['foo', 'bar']);
data.map(v => v.['foo', 'bar'])

It feels like the relationship between:

  1. Function.prototype.call and func()
  2. Array.prototype.at and arr[]

@js-choi
Copy link

js-choi commented Jan 16, 2024

Thanks @ljharb. So I guess there isn't very much that can be done right now. @js-choi do let me know if I can assist you in pushing this forward.

@jonkoops: This has been languishing because I have had little time over the past two years. But I do plan to keep pushing it as possible.

The biggest thing that would help me put together a plenary presentation to Stage 1 would be real-world examples illustrating the usefulness of object picking and omitting. Anyone can do this by searching for uses of Lodash/Underscore’s _.pick/omit, the object.pick NPM package, or whatever else in open-source codebases. Ideally the examples would be from well-known popular codebases: “mainstream” than “fringe” JavaScript.

Three real-world examples would probably be sufficient for me to make a compelling presentation to the plenary. I had planned to find these examples myself, but work has gotten in the way.

If you find any such examples, please feel free to open a new issue or pull request.

@aleen42: For what it’s worth, it’s considerably more difficult to add new syntax to the language, so the Committee is much more stringent about adding new syntax to the language than new built-in functions. (Note that there’s a proposal for array-slice syntax that has gotten bogged down due to this difficulty for new syntax.) I am inclined to not propose new syntax for this when a function would be good enough for its core use case of dynamic object “slicing”.

@jonkoops
Copy link

Sure, I can go around and see if I can find some common real-world examples. I imagine that these will all be rather similar in implementation considering the minimal API surface.

Do you require the references to the various code-bases that it would be sourced from? Or would a simplified implementation of such examples suffice?

@theScottyJam
Copy link

@jonkoops - for an easy way to search for prior art, take a look at https://github.com/tc39/proposal-call-this, at the "What methodology was used to get these results?" section. It talks about a file you can download that contains tons of source code from lots of different projects mushed together - so if you can think of a good search term (which may be the difficult part here), then you can easily search through the file for places of interest.

@jonkoops
Copy link

Thanks @theScottyJam, I'll use that as a reference!

@js-choi
Copy link

js-choi commented Jan 16, 2024

@jonkoops: Simplified minimal examples of picking and omitting, with references to the original uses, would be best. Look at the real-world examples section in the Array.fromAsync proposal for what I need.

Like @theScottyJam pointed out, the Gzemnid dataset can be useful to find prior art. You can also look at the lodash.pick, object.pick, and other NPM packages to find their most-popular dependent packages.

For example, here are the dependents of the lodash.pick package. In a few of the most popular dependents, you could then search their codebases for pick/omit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants