On Tue, Sep 24, 2013 at 6:49 PM, Kevin Smith <zenparsing at gmail.com> wrote:
> ## Symbols ##
>
> As it currently stands, the only thing that symbols provide is an isolated
> namespace for meta-level property keys.  This assures us that arbitrary
> string keys will not collide with any meta-level property names.  But going
> forward, arbitrary string keys should be stored *in a Map*, not as
> properties on an object.

This seems like a non-sequitur.  Symbols aren't meant to help with the
"object as map" use-case, and even if you tried to, they work terribly
for it.  They're meant for the "add an actual property/method without
collision" use-case.  Again, Maps seem like a non-sequitur here -
using a Map doesn't aid with avoiding collisions.

> Instead of symbols, a namespaced, non-identifier string key can be used for
> meta-level property names (e.g.):
>
>     class C {
>       "std:iterator"() { ... }
>     }
>
> This is more convenient than symbols, serves the purpose equally well, and
> it requires no additional primitive types.  In addition, string keys require
> no special-casing for representation in debugging tools.  Simpler is
> better-er.

How is this in any way better than:

class C {
  std_iterator() { ... }
}

?

~TJ

On Tue, Sep 24, 2013 at 6:49 PM, Kevin Smith <zenparsing at gmail.com> wrote:
> ## Symbols ##
>
> As it currently stands, the only thing that symbols provide is an isolated
> namespace for meta-level property keys.  This assures us that arbitrary
> string keys will not collide with any meta-level property names.  But going
> forward, arbitrary string keys should be stored *in a Map*, not as
> properties on an object.

This seems like a non-sequitur.  Symbols aren't meant to help with the
"object as map" use-case, and even if you tried to, they work terribly
for it.  They're meant for the "add an actual property/method without
collision" use-case.  Again, Maps seem like a non-sequitur here -
using a Map doesn't aid with avoiding collisions.

> Instead of symbols, a namespaced, non-identifier string key can be used for
> meta-level property names (e.g.):
>
>     class C {
>       "std:iterator"() { ... }
>     }
>
> This is more convenient than symbols, serves the purpose equally well, and
> it requires no additional primitive types.  In addition, string keys require
> no special-casing for representation in debugging tools.  Simpler is
> better-er.

How is this in any way better than:

```js
class C {
  std_iterator() { ... }
}
```

?

~TJ