why NextJob?

[Michael Dyck]

On 15-05-18 03:09 PM, Allen Wirfs-Brock wrote:
>
> On May 18, 2015, at 10:17 AM, Michael Dyck wrote:
>
>> As far as I can see, this has the same semantics as the current spec [..], but it's simpler, since:
>> (a) it doesn't need to introduce NextJob [...]
>> (b) it doesn't need to introduce Job [...]; and
>> (c) it 'explicitizes' the repeatedness of picking a Job Queue and running its front job.
>>
>> 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.

Ah, okay, I thought there was some advantage of the NextJob approach (either 
now, or when it was introduced) that I was missing.

> Once that spec work was done (a) and (b) are largely irrelevant
> because the work has already been done

I find this statement puzzling, given how much time you yourself have spent 
simplifying work that "has already been done".

In general, I believe that simplification (where possible) is very relevant 
to the readers of the spec.

-Michael