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.

Sign up for GitHub

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

Jump to bottom

Stop using function-call notation #34

Closed
domenic opened this issue Sep 23, 2013 · 4 comments
Closed

Stop using function-call notation #34

domenic opened this issue Sep 23, 2013 · 4 comments
Assignees
@domenic
Labels
editorial make-like-es-spec
Milestone
Editorially complete

Comments

@domenic
Copy link
Owner

domenic commented Sep 23, 2013

The ES spec, unfortunately, prefers verbose things like

Return the result of calling the [[X]] internal method of y passing z and w as the arguments.

Whereas I have written things as

Return y.[[X]](z, w).
@domenic
Copy link
Owner Author

domenic commented Oct 7, 2013

@allenwb, looking at the draft, I am confused about best practice for abstract operations that are not internal methods of objects. It seems clear that for internal methods, you use the "return the result of ..." quoted above. But for general abstract operations, I see any of:

Let replStr be the result of the abstract operation GetReplaceSubstitution(matched, string, pos, captures).

Let rx be the result of the abstract operation RegExpCreate (21.2.3.3) with arguments regexp and undefined.

Let next be the result of IteratorStep(iterator).

Let nextValue be IteratorValue(next).

Obviously I'm a fan of the last one. Which should it be? And any thoughts on the internal methods case?

@ghost ghost assigned allenwb Oct 7, 2013
@domenic domenic mentioned this issue Oct 8, 2013
Closed
domenic added a commit that referenced this issue Oct 13, 2013
@domenic
Add "Abstract Operations for the Promise Constructor."
7c8f40d 
This puts "newly-created Promise object" on more solid ground and helps separate the steps more clearly.

As part of this all new text was written keeping the formatting and editorial tweaks of #34, #37, and #49 in mind.
@domenic
Copy link
Owner Author

domenic commented Oct 13, 2013

I have settled on

Let next be the result of calling AbstractOperation(arg1, arg2).

This is largely done except inside operations which I still anticipate other revisions for.

@allenwb
Copy link
Collaborator

allenwb commented Oct 16, 2013

any of these are fine. Depending upon the phase of the moon I might change such things. But probably not.

@ghost ghost assigned domenic Oct 16, 2013
domenic added a commit that referenced this issue Oct 28, 2013
@domenic
Large rewrite of internals to satisfy subclassing constraints.
002ec7a 
This rewrite was the result of many discussions, starting in #54, but continuing into countless IM and email conversations. There were several competing concerns that arose, and I think this satisfies them all.

This rewrite is inspired largely by @rossberg-chromium's https://github.com/rossberg-chromium/js-promise/blob/master/promise.js, although there were many modifications necessary to make it work and pass all the tests.

In the end, the guiding principles seem to be:

- Store resolution value and rejection reason, instead of trying to extract a fulfillment value from the resolution value.
- Centralize all unwrapping in `then`, both on the input side (done by Promise Resolution Handler Functions) and the output side (done by Promise Reaction Functions).
- Do not differentiate between promises, promise subclasses, and thenables; use the `then` interface to send messages to all of them.
- More generally, do not use abstract operations when methods will do. Abstract operations should only supply the default implementation of methods.

As part of this rewrite, several other issues were addressed; #36 was started on, and most editorial and formatting issues (#34, #37, #49) were taken care of. This also closes #60 by virtue of that function no longer existing.

Note that the thenable coercions weak map was temporarily removed; it will be added back later (#39 #61).
@domenic
Copy link
Owner Author

domenic commented Oct 28, 2013

Fixed by tonight/this morning's commits.

@domenic domenic closed this as completed Oct 28, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@domenic domenic

Labels
editorial make-like-es-spec
Projects
None yet
Milestone
Editorially complete
Development

No branches or pull requests
2 participants
@allenwb @domenic