Does Symbol.split, Symbol.search etc. have to be in the Symbol namespace?
claude.pache at gmail.com
Tue Mar 17 14:17:26 UTC 2015
* 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.
> Le 15 mars 2015 à 03:18, Leon Arnott <leonarnott at gmail.com> a écrit :
> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss