@erights Mark Miller (Agoric) MM: One of the original reasons for sync callbacks was related to this quote from Dean Tribble that is reposted in the README for the cancellation proposal:

Cancellation is a race
In an async system, new activities may be getting continuously scheduled by asks that are themselves scheduled but not currently running. The act of cancelling needs to run in this environment. When cancel starts, you can think of it as a signal racing out to catch up with all the computations launched to achieve the now-cancelled objective. Some of those may choose to complete (see the caching example above). Some may potentially keep launching more work before that work itself gets signaled (yeah it's a bug but people write buggy code). In an async system, cancellation is not prompt. Thus, it's infeasible to ask "has cancellation finished?" because that's not a well defined state. Indeed, there can be code scheduled that should and does not get cancelled (e.g., the result processor for a pub/sub system), but that schedules work that will be cancelled (parse the publication of an update to the now-cancelled query).

Another reason for sync notification is that it ensures an entire cancellation graph can be set to the canceled/aborted state all at once, rather than incrementally as each notification triggers cancellation of a linked signal.

class { #x = 1 } means:

1. declare a private name
2. create a private propety with that name
3. assign it to 1
   private #x; class { #x = 1 } syntactically moves 1

ljharb:

class ROT {
  constructor(o) { return o; }
}

class Stamp extends ROT {
  #value;
  constructor(o, value) {
    super(o);
    this.#value = value;
  }
}
let stamp = (o, value) => { new Stamp(o, value); };

const obj = {};
stamp(obj, 1);
stamp(obj, 2); // error

is your proposal:

• this stops erroring?
• or, if you put private #x at the top, now it stops erroring?

Under Jordan's suggestion:

private #speak;
class Parent {
  constructor() {
    this.#speak();
  }

  #speak () {
    console.log('parent');
  }
}

class Child extends Parent {
  #speak() {
    console.log('child')
  }
}

new Child(); // "parent"

But if we kept the "can't install twice", this throws. I like the throwing.

alternative for (always) sorting is two phase api:

const makeRGB = defineComposite("r", "g", "b");

function RGB(o) {
  return makeRGB(o.r, o.g, o.b);
}


RGB(...) -> #Composite { b: _, g: _, r: _  }

About the export * from refactoring hazard, to be clear it's this:

// entry.js
export * from "a.js";
export * from "b.js";

// a.js
export let a = 1;
export default 2;

// b.js
export let b = 3;

with this proposal entry.js would export a, default, and b.

If b.js adds a default export, then entrty.js will only export a and b. This is the same as if b.js added an a export, then entry.js will stop exporting a.

It is true that adding a default export is more likely than adding a a export, but it's also something that will be caught very easily