Symbol.inspect
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.
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 tc39/proposal-javascript-standard-library#47 to elaborate on this further.
Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com
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.