On Sat, Jun 13, 2015 at 11:39 AM, Benjamin Gruenbaum <benjami...@gmail.com> wrote:
> On Sat, Jun 13, 2015 at 9:07 PM, Mark S. Miller <erig...@google.com> > wrote: > >> On Sat, Jun 13, 2015 at 9:17 AM, Domenic Denicola <d...@domenic.me> wrote: >> >>> All of these should be building on top of RegExp.escape :P >>> >> >> It's funny how, by considering it as leading to a proposal, I quickly saw >> deep flaws that I was previously missing. >> >> > That was a big part of making a proposal out of it - to find these things > :) > Indeed! Much appreciated. > > >> the overall result does not do this. For example: >> >> const data = ':x'; >> const rebad = RegExp.tag`(?${data})`; >> console.log(rebad.test('x')); // true >> >> is nonsense. Since the RegExp grammar can be extended per platform, the >> same argument that says we should have the platform provide RegExp.escape >> says we should have the platform provide RegExp.tag -- so that they can >> conisistently reflect these platform extensions. >> >> > This is a good point, I considered whether or not `-` should be included > for a similar reason. I think it is reasonable to only include syntax > identifiers and expect users to deal with parts of patterns of more than > one characters themselves (by wrapping the string with `()` in the > constructor). This is what every other language does practically. > > That said - I'm very open to allowing implementations to escape _more_ > than `SyntaxCharacter` in their implementations and to even recommend that > they do so in such a way that is consistent with their regular expressions. > What do you think about doing that? > > I'm also open to `.tag` wrapping with `()` to avoid these issues but I'm > not sure if we have a way in JavaScript to not make a capturing group out > of it. > Better or different escaping is not issue of this first bullet, but rather, validating that a fragment is a valid fragment for that regexp grammar. For the std grammar, "(?" is not a valid fragment and the tag should have rejected the template with an error on that basis alone. > > >> * Now that we have modules, I would like to see us stop having each >> proposal for new functionality come at the price of further global >> namespace pollution. I would like to see us transition towards having most >> new std library entry points be provided by std modules. I understand why >> we haven't yet, but something needs to go first. >> >> > I think that doing this should be an eventual target but I don't think > adding a single much-asked-for static function to the RegExp function would > be a good place to start. I think the committee first needs to agree about > how this form of modularisation should be done - there are much bigger > targets first and I would not like to see this proposal tied and held back > by that (useful) goal. > I agree, but this will be true for any individual proposal. Perhaps we need a sacrificial "first penguin through the ice" proposal whose *only* purpose is to arrive as a std import rather than a std primordial. (Just kidding.) > > >> * ES6 made RegExp subclassable with most methods delegating to a common >> @exec method, so that a subclass only needs to consistently override a >> small number of things to stay consistent. Neither RegExpSubclass.escape >> nor RegExpSubclass.tag can be derived from aRegExpSubclass[@exec]. Because >> of the first bullet, RegExpSubclass.tag also cannot be derived from >> RegExpSubclass.escape. But having RegExpSubclass.escape delegating to >> RegExpSubclass.tag seem weird. >> >> > Right but it makes sense that `escape` does not play in this game since it > is a static method that takes a string argument - I'm not sure how it could > use @exec. > I agree that defining a class-side method to delegate to an instance-side method is unpleasant. But because we have class-side inheritance, static methods should be designed with this larger game in mind. > > >> * The instanceof below prevents this polyfill from working cross-frame. >> Also, when doing RegExpSubclass1.tag`xx${aRegExpSubclass2}yy`, where >> RegExpSubclass2.source produces a regexp grammar string that >> RegExpSubclass1 does not understand, I have no idea what the composition >> should do other than reject with an error. But what if the strings happen >> to be mutually valid but with conflicting meaning between these subclasses? >> >> This is hacky, but in my code I just did `argument.exec ? treatAsRegExp : > treatAsString`. > Yes, as with instanceof, that's the difference between the quality needed in a polyfill for personal use vs a proposed std. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss