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

Should Symbol.species be consulted #14

Closed
acutmore opened this issue Jul 6, 2021 · 4 comments
Closed

Should Symbol.species be consulted #14

acutmore opened this issue Jul 6, 2021 · 4 comments

Comments

@acutmore
Copy link

acutmore commented Jul 6, 2021

Hi! As part of proposal-change-array-by-copy we have been discussing not consulting Symbol. Species when constructing the return values.

tc39/proposal-change-array-by-copy#33

There hasn't been new methods added to Array since https://github.com/tc39/proposal-rm-builtin-subclassing was presented so the next proposal that does may set a precedence.

@zloirock
Copy link
Contributor

zloirock commented Jul 6, 2021

One more time: this proposal will break the web. Until it will not be rewritten to recommend something for new features instead of removing existing features, it makes no sense to rely on it.

@acutmore
Copy link
Author

acutmore commented Jul 7, 2021

There is also discussion in https://github.com/tc39/ecma262/pull/2360/files about not encouraging extending builtins.

Maybe this will apply to new methods that don't already exist on the web.

@zloirock
Copy link
Contributor

zloirock commented Jul 7, 2021

I don't see any decision about the standard new approach - subclassing of instance methods should be completely removed (that is differently a mistake - it's actively used in wild, some examples by the link above), should be an alternative of @@species or this kind of subclassing will remain as it is? Wait some more years for the decision about this proposal and block all proposals that it could affect is a bad idea. Until the new approach is not approved, should be used the way that is a standard at this moment.

It's an array method and @@species pattern was added mainly for arrays.

Make Array#filter and Array#filterOut different in one more case definitely a bad idea.

@jridgewell
Copy link
Member

I don't want hold up the proposal by trying to trailblaze, and we've seen other proposals fail to reach consensus because they try. Until there's full consensus on the subclassing (or what level of subclassing) by the committee, I think making Array methods that don't allow species is a mistake.

Make Array#filter and Array#filterOut different in one more case definitely a bad idea.

Agreed. I'm not comfortable making filterOut diverge from filter (besides the obvious). Even if we had consensus on subclassing, I would still argue filterOut should match filter exactly.

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

3 participants