Proposal: Symbol Linked to `typeof`

Jordan Harband ljharb at gmail.com
Tue Jan 15 23:52:57 UTC 2019


Symbol.toStringTag can be used for this purpose now (and it already
unfortunately destroyed the reliability of
`Object.prototype.toString.call`).

On Tue, Jan 15, 2019 at 3:07 PM Randy Buchholz <work at randybuchholz.com>
wrote:

> 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 <es-discuss-bounces at mozilla.org> * On Behalf Of *Jordan
> Harband
> *Sent:* Tuesday, January 15, 2019 3:36 PM
> *To:* J Decker <d3ck0r at gmail.com>
> *Cc:* es-discuss at mozilla.org
> *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 <d3ck0r at gmail.com> wrote:
>
>
>
>
>
> On Sat, Jan 12, 2019 at 8:19 AM Randy Buchholz <work at randybuchholz.com>
> 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
>
> "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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190115/a517146f/attachment.html>


More information about the es-discuss mailing list