why NextJob?

[Allen Wirfs-Brock]

On May 18, 2015, at 10:17 AM, Michael Dyck wrote:

> Can someone explain to me why the spec needs NextJob?
> 
> Consider this alternative:
> -- Replace every invocation of 'NextJob' with 'Return'.
> -- Introduce a top-level abstract operation for them to return *to*:
> 
>   1. Call Initialization().
>   2. Repeat:
>        a-h. [steps 2-9 of NextJob]
>        i. Let /result/ be the result of performing the abstract operation
>           named by /nextPending/.[[Job]] etc.
>        j. If /result/ is an abrupt completion, etc.
> 
> As far as I can see, this has the same semantics as the current spec (i.e., requires the same behavior from implementations), but it's simpler, since:
> (a) it doesn't need to introduce NextJob as a different way for abstract operations to terminate;
> (b) it doesn't need to introduce Job as a class of abstract operation that must call NextJob rather than Return or ReturnIfAbrupt; and
> (c) it 'explicitizes' the repeatedness of picking a Job Queue and running its front job.
> 
> Or, as another alternative, consider Ian Hickson's 'RunCode' suggestion:
> https://esdiscuss.org/topic/the-initialization-steps-for-web-browsers#content-9
> which (IIUC) still has advantages (a) and (b).
> 
> Given the alternatives, why does the spec use NextJob?

Because that was the design I came up with when I introduced the Job concept into the spec.  Obviously, other semantically equivalent designs are possible.  Once that spec work was done (a) and (b) are largely irrelevant because the work has already been done and (c) is insufficient reason to redo the work.

Allen