Does Symbol.split, etc. have to be in the Symbol namespace?

Leon Arnott leonarnott at
Wed Mar 18 00:50:54 UTC 2015

On Wed, Mar 18, 2015 at 12:17 AM, Claude Pache <claude.pache at>

> Some thoughts:
> * You ain't need objects to implement "namespaces"; simply use a prefix:
> `Symbol.RegExp_search`. One advantage to have all well-known symbols on
> `Symbol` (or any other adhoc object), is that you can get the list of them
> simply by looking up the keys of `Symbol`.

Colour me unimaginative, but I question whether there's ever a point to
retrieving every WKS, regardless of what they are or where they're used.
The ones in ES6 are already radically different from each other, and the
ES7-8-9-10 additions aren't likely to be any less esoteric. And I think
underscores are not in keeping with the current built-ins unless
accompanied with all-caps (but then again, the symbol names - static value
properties - don't use all-caps either).

> * We could consider to reuse "search" for some method name, e.g. because
> it is sufficiently similar to String#search, but we could also consider to
> reuse @@search for something else than RegExp#@@search for the same reason.

This sounds a bit like post-hoc wishful thinking to me.

But, OK, let's entertain this: what if in ES7, (etc.) could
be attached to any arbitrary object, such that the object, when passed to
String#search, would, by virtue of having the method, *not* be
auto-converted to RegExp? (I think the likelihood of ES6 production code
requiring non-RegExp objects with keys to still be converted
to RegExp when passed to String#search would be very close to zilch.) I'd
feel a bit better about the naming of these symbols if this was the case.

Uses? Well, you could, for instance, make a subclass or instance of
Function with a method that was something like `return
this(string)`, thus letting you pass it as a callback to String#search.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list