My thought was Symbol.typeof could improve both reliability and flexibility. It could be abused, but no more than Symbol.toStringTag. My use case is putting classes into “namespaces”. With [Symbol.typeof] = “Collections.Lists.LinkedList”, I can get the qualified type of the object. I can also use this in my IDE to keep my classes organized if I write tools to help me. Since imports use paths, if I move a file refactoring can be painful. With an IDE extension, I can trigger an event when I move a file to prompt “Update all imports?”. It can parse my project and update all imports to point to the right place.
From: es-discuss <[email protected]> On Behalf Of Jordan Harband Sent: Tuesday, January 15, 2019 3:36 PM To: J Decker <[email protected]> Cc: [email protected] Subject: Re: Proposal: Symbol Linked to `typeof` `.constructor` is unreliable, and can be easily forged - of course, `Symbol.typeof` would create the same unreliability with one of the few truly reliable operators in the language. On Tue, Jan 15, 2019 at 12:38 PM J Decker <[email protected]<mailto:[email protected]>> wrote: On Sat, Jan 12, 2019 at 8:19 AM Randy Buchholz <[email protected]<mailto:[email protected]>> wrote: (Hi all, new to group) Some of the Well Known Symbols are linked to standard functions – Symbol.toStringTag - A string value used for the default description of an object. Used by Object.prototype.toString(). When I have a Class instance (say, `const flow = new Flow()`, the debugger shows `flow = Flow {`. But when I do `console.log( typeof flow)` the output is `object`. I assume changing basic behavior `typeof` would be breaking, but extending it through a symbol would be useful. `Symbol.typeofTag` of just `Symbol.typeof` Invoking `typeof` on an object with this symbol would return “user-typed” information. can't you just use the constructor name when needing more detail? var a = new Date(); a.constructor.name<http://a.constructor.name> "Date" (Posting Question) What is the preferred format/approach for highlighting code in posts? ____________________ Possible Approaches ``` class Flow { get [Symbol.typeof]() { return Flow; } or { return “Flow” } } ``` would work much like Symbol.species. Implicitly casting to string would be more intuitive I think. Other approaches, (special handling of well-knowns) could be: Decorator-ish ``` [Symbol.typeof] = “Flow” Class Flow {… ``` or inferred ``` [Symbol.typeof] class Flow {… ``` Internal – In class, but not in a function. ``` Class Flow { [Symbol.typeof] or [Symbol.typeof] = “Flow” or [Symbol.typeof] = Flow or [Symbol.typeof] = this ``` Constructor ``` Class Flow { Constructor() { this[Symbol.typeof] = … … ``` _______________________________________________ es-discuss mailing list [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
