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

Leon Arnott leonarnott at
Sun Mar 15 02:18:52 UTC 2015

I've taken some umbrage for awhile about the placement of Symbol.match,
Symbol.split,, and Symbol.replace. Unlike almost every other
well-known symbol (WKS), these denote methods that apply only to RegExps. A
plain object can do something with a Symbol.isConcatSpreadable or
Symbol.toPrimitive-keyed property, but is irrelevant to it.
This distinction is sadly not obvious from the name.

Also, I think there's a case to be made that these names "pollute" the
Symbol namespace -, for instance, doesn't properly convey
that it relates only to RegExps, because "search" is such a general term.
If a distant future built-in were to have a "search" method (which is
unlikely given that Array has decided to instead use "find", but just as an
example) then its lack of relevance to would be irksome.

I wonder if there shouldn't instead be a sub-namespace inside Symbol that
should properly contain those symbols that only relate to RegExps:
Symbol.split -> Symbol.RegExp.split ->
Symbol.replace -> Symbol.RegExp.replace
Symbol.match -> Symbol.RegExp.match
Alternatively, I wonder if a reverse approach is possible: making a
RegExp.Symbol object and putting them there:
Symbol.split -> RegExp.Symbol.split ->
Symbol.replace -> RegExp.Symbol.replace
Symbol.match -> RegExp.Symbol.match
Both of these look much more tidy and clean than just having Symbol.split
etc. alongside the other WKS, as if they're equivalent.

Incidentally, I'm aware of two other WKS that only relate to a certain
built-in class: Symbol.species and Symbol.hasInstance. I wonder if it would
be possible to move these to Symbol.Function.species or
Function.Symbol.species, etc., if the proposal above seems sound.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list