Yeah, I agree that until the ECMAScript spec defines any I/O APIs, it
doesn't belong in the spec. The spec is great for things that involve
pure data processing, but anything beyond that should be left to
embedders ("hosts" in the spec) to define.I do feel that a separate spec dependent on ES should exist for stuff that goes above and beyond simple data processing but is still broadly useful in standard mobile/desktop/browser/server runtimes, like: - Workers - Web requests, specifically just the `fetch(string, opts?)` part + associated response APIs - Native cryptography APIs - WebAssembly integration - Off-screen GPU access with permitted CPU fallback, useful for image processing and large-scale data processing on server-side and client-side This would be things the *host* would implement, ideally as standard library modules, not the *engine*. Each of these would be optional, but the HTML spec should require hosts to implement most modules within it. I've filed https://github.com/tc39/proposal-javascript-standard-library/issues/47 to elaborate on this further. ----- Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Thu, Apr 4, 2019 at 9:18 PM Logan Smyth <loganfsm...@gmail.com> wrote: > > Symbols seems like a good way to do this, but since the ECMA spec doesn't > define anything about IO, I don't think this would be their responsibility. > This seems more like something the console API spec would expose, e.g. > `console.inspect`, where the `Symbol.XX` namespace would be reserved for > ECMAScript-builtin symbols. > > On Thu, Apr 4, 2019 at 5:44 PM Sultan <thysul...@gmail.com> wrote: >> >> Like Symbol.iterator, a Symbol.inspect symbol for use in implementing >> cross-platform console display introspection. >> >> Currently node has something akin to this with a magic inspect method on >> objects. >> >> This would pave a cow path for how different platforms can afford this >> ability to consumers without each inventing their own heuristic, i.e in the >> browser i might have an exotic object that i want console.error to display a >> toString payload instead of the objects shape. >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
