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. —Claude > Le 15 mars 2015 à 03:18, Leon Arnott <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
