Alarms are represented by unique, "truthy" values. This would be the first time using "truthy" in the JS spec, that's in an associated set with the waiter list. Alarms have a function inside of them. This is always a built-in function for the same abstract algorithm. I'd suggest that we just inline that algorithm where the function is called, and save all of this indirection and confusion.
Could we represent an alarm as a record instead, which contains the values that are put into the alarmFn's internal slots? And, rather than putting them into a WL's alarm set, just include them in the record set up in #14? Rather than checking whether an alarm is cancelled by seeing if it's present in the WL, the alarm could have a record field indicating whether it's been cancelled. Finally, rather than using false as the absence of an alarm, we could use undefined (or null).
Alarms are represented by unique, "truthy" values. This would be the first time using "truthy" in the JS spec, that's in an associated set with the waiter list. Alarms have a function inside of them. This is always a built-in function for the same abstract algorithm. I'd suggest that we just inline that algorithm where the function is called, and save all of this indirection and confusion.
Could we represent an alarm as a record instead, which contains the values that are put into the alarmFn's internal slots? And, rather than putting them into a WL's alarm set, just include them in the record set up in #14? Rather than checking whether an alarm is cancelled by seeing if it's present in the WL, the alarm could have a record field indicating whether it's been cancelled. Finally, rather than using
falseas the absence of an alarm, we could useundefined(ornull).