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

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


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150318/bce46b02/attachment-0001.html>


More information about the es-discuss mailing list