Calling language functions at first seemed unnecessarily expensive to me. I just did a bit of research, and it looks like I was wrong about replacing search with indexOf. That will only work for simple string searches. str.search(“.”) will always return 0 unless the string is empty, because the “.” is evaluated to new RegExp(“.”). This is true both in Flash and JS environments. The “?” case seems to be an outlier. Either way, I’m not sure how my code ever worked. str.match(“?”) seems to always return null.
Language functions seem like they are more expensive, but you might be right that it might be the best way to go. The implementation should probably use a try/catch to construct a RegExp object from the string and return null/-1 if the constructor causes an error. That would be the same as the Flash implementation. We could also use debug.warn() to let the developer know that using strings is not recommended. Harbs > On Jul 18, 2017, at 6:37 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > This feels like something that the compiler should just call > Language.stringMatch and Language.stringSearch (or standalone > equivalents). I'm not clear that we should always modify the string. By > calling new utility functions, the developer has control over the > conversion. > > -Alex > > On 7/18/17, 4:11 AM, "Harbs" <harbs.li...@gmail.com > <mailto:harbs.li...@gmail.com>> wrote: > >> The same issue applies to String.search(), although it might make sense >> to replace String.search() with String.indexOf() if the parameter is a >> string. >> >>> On Jul 18, 2017, at 12:36 PM, yishayw <yishayj...@hotmail.com> wrote: >>> >>> In flash String.match() can take either a string or a regex. In JS it's >>> always considered to be a regex. So str.match("?") is valid in flash but >>> will fail in JS. We ran into that porting our app which includes some >>> code >>> to test for url params. >>> >>> So maybe the compiler should identify that the input is a string and >>> replace >>> all special chars as suggested here [1]? >>> >>> [1] >>> >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackove >>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackove> >>> rflow.com >>> <http://rflow.com/>%2Fquestions%2F3561493%2Fis-there-a-regexp-escape-function-in-ja >>> vascript&data=02%7C01%7C%7C2260cdfd26d74274ba4a08d4cdcde8ea%7Cfa7b1b5a7b3 >>> 4438794aed2c178decee1%7C0%7C0%7C636359731646059595&sdata=LKSeBWNfrL6CCQRg >>> eMI48HJSvACdKoNp5X3AZuMoZeU%3D&reserved=0 >>> >>> >>> >>> >>> -- >>> View this message in context: >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl >>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl> >>> ex-development.2333347.n4.nabble.com >>> <http://ex-development.2333347.n4.nabble.com/>%2FFlexJS-String-match-tp63392.html&d >>> ata=02%7C01%7C%7C2260cdfd26d74274ba4a08d4cdcde8ea%7Cfa7b1b5a7b34438794aed >>> 2c178decee1%7C0%7C0%7C636359731646069605&sdata=X0ZlS9B3AUiglpM5ywHSi4aqui >>> jF55mWfBbbEfnJE6E%3D&reserved=0 >>> Sent from the Apache Flex Development mailing list archive at >>> Nabble.com <http://nabble.com/>.
