Let's restrict custom `typeof` values to just symbols - objects are
unnecessarily weighty, strings would break a lot of code, and other
primitives are generally useless.
A property sounds compelling, and I feel like I saw it suggested a while
back (forget where) something similar by a TC39 person.
On Sat, Jan 12, 2019 at 8:19 AM Randy Buchholz
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
`.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 wrote:
>
>
> On Sat, Jan 12, 2019 at 8:19 AM Randy Buchholz
> wrote:
>
point
to the right place.
From: es-discuss On Behalf Of Jordan Harband
Sent: Tuesday, January 15, 2019 3:36 PM
To: J Decker
Cc: es-discuss@mozilla.org
Subject: Re: Proposal: Symbol Linked to `typeof`
`.constructor` is unreliable, and can be easily forged - of course,
`Symbol.typeof` would create
scuss * On Behalf Of *Jordan
> Harband
> *Sent:* Tuesday, January 15, 2019 3:36 PM
> *To:* J Decker
> *Cc:* es-discuss@mozilla.org
> *Subject:* Re: Proposal: Symbol Linked to `typeof`
>
>
>
> `.constructor` is unreliable, and can be easily forged - of course,
> `S
I could definitely see usage of this when using custom Constructors. But this
could confuse current code of JS:
```js
function A(B, C) {
if(typeof B === ‘string’) // ...
}
A({[Symbol.typeof]: ‘string’})
```
This would make new code to use not only `typeof B === ‘String’`, but also `B
instan
Right. Misappropriating a symbol corrupts its intent. As ES moves in a more
towards a more "class-ish" feel, and people start writing more classes, a
type/namespace system isn't far behind. Implementing some symbols to support
this helps drive some standard approaches and discourages symbol
mis
I don't think string namespaced names are the right feature here
Namespaces are intended mainly to avoid conflicts with names when
sharing a global scope (like when using classpath in Java, or libs in
C++)
Javascript already solves this problems with modules, you can always
guard your code with in
https://github.com/michaelficarra/proposal-first-class-protocols may be
relevant.
On Wed, Jan 16, 2019 at 9:06 AM Augusto Moura
wrote:
> I don't think string namespaced names are the right feature here
>
> Namespaces are intended mainly to avoid conflicts with names when
> sharing a global scope
@Augusto Moura, I like the approach using `hasInstance`.
It may be just me, but having your software architecture hardcoded to your
filesystem (even with logical roots) feels shaky. (and so 1970’s 😊). Namespaces
serve the purpose you stated at compile/runtime, but also serve as a form of
human
The module system is not filesystem based, but URL based, that's a lot
of differences between the two, URLs are designed to be unique and be
storage/protocol agnostic in most networks. Others languages are
following similar paths, Go for example even allows you to import
entire github projects dire
Your Absolutely right! My mistake.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
12 matches
Mail list logo
