API shape

[mikesamuel]

@littledan raised this during Q&A.

Other thing to iterate on: static method vs built-in module. Last time discussed: thoughts about integrity properties. If moving towards built-in modules, if several JS environments use import-maps to centralize polyfilling built-in modules, then using built-in modules would be good.

My understanding is that the question is whether this would be used via

// Static method (currently speced)
Array.isTemplateObject(o)

// Built-in modules
import { isTemplateObject } from '@std/template-object';

[mikesamuel]

if several JS environments use import-maps to centralize polyfilling built-in modules, then using built-in modules would be good.

+1

But I'd rather not have this go up for stage 4 and get rejected because some detail of standard libraries still need to be hashed out, and I don't know of examples of proposals that have speced standard library modules.

Does anyone know how to draft spec text for a builtin function?

The spec abstraction should be reviewable independently of the API.

Actionable: the test262 tests can be made flexible via

const { isTemplateObject } = Array;

/*
tests that use isTemplateObject instead of Array.isTemplateObject.
*/

We might need to adjust a test that tests isTemplateObject works even when not called with the Array constructor as this value.

[ljharb]

This is stage 2. Builtin modules are stage 1. It makes no sense imo to chain a proposal to another in an earlier stage.

[mikesamuel]

For reference: JavaScript Standard Library Proposal

[mikesamuel]

The tests can be written against the polyfill (issue #8) which should gloss over the final API shape.

[littledan]

Just to clarify, I am fine with leaving this as a static method at this point. This is certainly the best strategy if we want this to become standard fast.

[mikesamuel]

Closing since, with the polyfill concerns extracted into issue #8, it looks like all commenters agree.