Stepping back: what are the constraints/requirements?

[domenic]

As previous issues in this tracker plus other offline discussions have revealed, my hypotheses as to what would be implementable are not very good. As such the API currently in the README is not a great representation of what we're trying to accomplish here, as it mixes up the problem space with the solution space.

Here's my first draft of goals and non-goals that should help make things clearer for anyone, like myself, who wants to rethink the solution space.

Goals

• Work in both window and worker contexts (probably worklet too)
• Span built-in JS (ECMAScript spec) and web (Web IDL) ecosystems
• Give the ability to do the original operation for:
  • Static methods (Array.isArray; URL.createObjectURL)
  • "Namespace" methods (JSON.parse; CSS.supports)
  • Prototype getters/setters (ArrayBuffer.prototype.byteLength; DOMTokenList.prototype.value)
  • Prototype methods (Promise.prototype.then; Event.prototype.preventDefault)
  • Global getters/setters (window.opener)
  • Global methods (createImageBitmap; encodeURIComponent)
  • Constructors (Promise; Event)
• For constructors or other "create a new object" methods, return instances from the correct realm (see current readme's "Same values" section)
  • E.g. not just constructors, but also document.createElement, window.createImageBitmap, node.childNodes, etc.... this is made worse by the web platform not having a uniform answer for what realm is chosen, see State that by default all objects are created in the relevant realm of this whatwg/webidl#135 and also State that by default all objects are created in the relevant realm of this whatwg/webidl#135 (comment)
• Usage does not make refactoring prototype chains over time more likely to break the web (see current readme's "Instance based design rationale" section)
• Be relatively efficient (at least in theory, with sufficiently smart implementations):
  • Invoking original operations should not be much slower than invoking things "normally"
  • Pages that use this API should not be worse in memory usage than pages that don't, ideally, or at least should pay only proportional to their use

Non-goals

• API is easy to use for humans. Primarily we would anticipate this being used by tools that convert idiomatic code into robust get-originals-using code.
• Getting the original value/doing the original operation for:
  • Static or global constants (NaN, Infinity, Range.START_TO_END, ...; see There is no decent way to get the original values of WebIDL constants #9)
  • Magic data properties (Array's length)
  • Data properties in general (array[0], error.message)
  • Things which don't have a global name (e.g. the original %TypedArray% constructor; see Getting original constructors without names #15)
  • Things which do not use any internal slots/brand checks and can thus be emulated in user code (see It looks like there is no way to call the original Array.prototype.map #8)

It is also a non-goal to support a way of stashing and retrieving the originals for user-supplied objects, although that would be vaguely nice if it falls out naturally from the design we end up with. (Related: drufball/layered-apis#32)

[domenic]

Let me suggest constraining your discussions to other threads, so we can use this for the design goals of the proposal authors. I'll collapse a number of comments here.