Skip to content

How to specify #11

@mgaudet

Description

@mgaudet

I think I have a rough idea of what we're looking for semantic wise:

  1. A notion of 'a value whose resolution should be deferred'
  2. The ability to get the promise-to-be-resolved into a state where it no longer could be resolved elsewhere
  3. A job, which when run, does the promise resolution steps. Because we've deferred a turn, this should be synchronous at the point where the job runs.

That being said, I am struggling a bit to write spec that hits these semantics. Partially as I'm trying to avoid being too invasive in the spec, but there's also plausibly gaps in my spec-writing-understanding.

One pitched proposal from plenary was the idea of having the promise-to-be-resolved be resolved with a new internal promise; then we hold onto the resolution function of the new internal promise, and resolve that with the value in when the deferral job runs.

The challenge here being that this mostly does what I want, except I think will be two ticks, not one tick of delay. The reason being that the internal promise's resolve function is created by CreateResolvingFunctions, which makes another job in the case of a then function. So we end up with two delays rather than 1.

So to avoid this extra state, I guess we need an alternative 'internal' promise constructor which can create the new promise, but with a different [[resolve]] function, which is the synchronous variant of the one created in CreateResolvingFunctions? However I am really not sure what this looks like.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions