On Wed, Mar 18, 2015 at 12:17 AM, Claude Pache <[email protected]> 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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
