I think the only reason new WatchSignal throws is because new AbortSignal throws. Generally you can subclass web platform objects.

I guess what you need is that when you instantiate a subclass of AbortController you need some kind of way to override the creation of an AbortSignal with another subclass. Perhaps using https://blog.domenic.me/the-revealing-constructor-pattern/?

And then perhaps AbortSignal.abort() and AbortSignal.timeout() need to be able to return a subclass when used on one. I think JavaScript has some capability for that as well, but I believe that feature is not much liked.

Overall though I think your rationale is sound and I think people generally appreciated being able to do this with EventTarget.

I think the only reason new WatchSignal throws is because new AbortSignal throws. Generally you can subclass web platform objects.

I've continued to experiment and did manage to successfully get them subclassing, but it's a bit of a pain to get working, and doesn't allow for class fields or constructor initialisation logic in the signal:

class WatchSignal extends AbortSignal {
  get watching() {
    return !this.aborted
  }
}

class WatchController extends AbortController {
  constructor() {
    super()
    // Here is the magic line:
    Object.setPrototypeOf(this.signal, WatchSignal.prototype)
  } 
}

const wc = new WatchController()
console.assert( wc.signal.watching )

Doing it this way also means class fields wont be assigned and private fields won't work.

And then perhaps AbortSignal.abort() and AbortSignal.timeout() need to be able to return a subclass when used on one. I think JavaScript has some capability for that as well, but I believe that feature is not much liked.

[Symbol.species] but I think that is recommended against and being proposed for removal.

Perhaps using https://blog.domenic.me/the-revealing-constructor-pattern/?

I like the pattern but I struggle to see how it could apply to this considering we have two discrete objects which share a private API:

class WatchSignal extends AbortSignal {
  constructor(abort) {
    super(abort)
  } 
}

class WatchController extends AbortController {
  constructor() {
    super(function (abort) { // What is even `abort`? Maybe userland doesn't care?

      // Presumably we need to return an AbortSignal instance
      // to have AbortController assign this as the signal?
      return new WatchSignal(abort)
    })
  } 
}

I'm not entirely sure about that part either, but something like that. @domenic used to think about this problem space a fair bit and might have ideas.

@jakearchibald also had some insight about 2 years ago, in this thread: #981 (comment).

doesn't allow for class fields or constructor initialisation logic in the signal

Return override permits this.

class WatchSignal extends function(o) { return Object.setPrototypeOf(o, new.target.prototype); } {
  #fields = "here";
  
  static {
    Object.setPrototypeOf(this.prototype, AbortSignal.prototype);
  }
}

class WatchController extends AbortController {
  constructor() {
    new WatchSignal(super().signal);
  }
}

(Note the use of new.target.prototype in the “identity class”: honoring new.target.prototype permits further subclassing of WatchSignal without needing to do this again.)

Further refinements are possible if you want it to behave as closely as possible to a native platform interface object (really you need two classes to get it right, a “private” and “public” pair, so that the public constructor.[[Prototype]] becomes immaterial to what happens in the private constructor logic and no “implementation artifacts” are left hanging on the user-reachable outside surface), but things get increasingly complicated and “fussy” the deeper you go. Decorators will allow us to encapsulate a lot of that boilerplate much more neatly, but not exactly all of it.

I like the pattern but I struggle to see how it could apply to this considering we have two discrete objects which share a private API:

class WatchSignal extends AbortSignal {
  constructor(abort) {
    super(abort)
  } 
}

class WatchController extends AbortController {
  constructor() {
    super(function (abort) { // What is even `abort`? Maybe userland doesn't care?

      // Presumably we need to return an AbortSignal instance
      // to have AbortController assign this as the signal?
      return new WatchSignal(abort)
    })
  } 
}

It would probably make sense if it were just the controller itself, this also allows a subclass pair to share data between the controller and signal easily:

const activePriorities = new WeakMap();

class PrioritySignal extends AbortSignal {
    #priorityController;

    constructor(priorityController) {
        // AbortSignal can access the usual internal slots of the controller
        super(priorityController);
        // We can access whatever shared things we need of the watchController here too
        this.#priorityController = priorityController;
    }

    get priority() {
        return activePriorities.get(this.#priorityController);
    }
}

class PriorityController extends AbortController {
    constructor(initialPriority = 1) {
        super(controller => {
             return new PrioritySignal(controller);
        });
        activePriorities.set(this, initialPriority);
    }
}