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

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

# Leon Arnott (10 years ago)

I've taken some umbrage for awhile about the placement of Symbol.match, Symbol.split, Symbol.search, 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 Symbol.search 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 - Symbol.search, 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 Symbol.search 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.search -> Symbol.RegExp.search

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.search -> RegExp.Symbol.search

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.

# Claude Pache (10 years ago)

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.

  • It is good hygiene to avoid same-named methods for unrelated operations: for instance, we have Array#length but Set#size, because Set objects are not array-like. That consideration will reduce the chance to have another "search" method, for example.

  • 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.

# Leon Arnott (10 years ago)

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

wrote:

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, Symbol.search (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 Symbol.search 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 Symbol.search method that was something like return this(string), thus letting you pass it as a callback to String#search.