No. We thought that the “?” found the string in Flash. It does not.
trace("https://www.google.com/search?q=dogs".match("?"));
trace("https://www.google.com/search?q=dogs".search("?"));
trace("https://www.google.com/search?q=dogs".indexOf("?"));
outputs:
null
-1
29
> On Jul 21, 2017, at 12:00 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> I think I'm still confused. My current thinking is that in Flash there
> are strings you can pass in that are "invalid RegExp" that will still find
> matches in a string. Isn't that what Yishay showed? IOW, passing in just
> "?" in Flash will find question marks in a string but is an error in JS
> because it isn't valid RegExp.
>
> So, right now I think the utility function needs to catch the error and
> either escape the string so it is valid RegExp and call match() or use
> indexOf() and compute the same result. It should not always return null.
> Then I think it would completely implement how it worked in Flash and the
> users won't have to figure out how to regex-ify the strings in the apps
> they are porting.
>
> My 2 cents,
> -Alex
>
>
>
> On 7/20/17, 12:55 PM, "Harbs" <harbs.li...@gmail.com
> <mailto:harbs.li...@gmail.com>> wrote:
>
>> After all this discussion, I’m having second thoughts about this whole
>> thing.
>>
>> What’s the point of using an invalid RegExp that will not match anything?
>>
>> I think the JS behavior makes more sense than the Flash behavior. If a
>> RegExp is invalid, it should throw an error rather than never matching
>> anything. The use of such a RegExp in the first place can only be
>> described as a bug.
>>
>> “Fixing” the JS behavior to match the Flash behavior is the wrong thing
>> to do.
>>
>>> On Jul 20, 2017, at 10:34 PM, Harbs <harbs.li...@gmail.com> wrote:
>>>
>>> new RegExp({})
>>> returns:
>>> /[object Object]/
>>>
>>> I think the wrapping that I did in the code I already committed is
>>> correct:
>>>
>>> try{return input.match(pattern);}
>>> catch (e:Error){return null;}
>>>
>>> If the try fails, that means the RegExp is an invalid expression and
>>> will not match anything in Flash. In that case, match should always
>>> return null and search should always return -1.
>>>
>>> I do think that warning developers against using strings is a good
>>> idea. Accepting any value and automatically converting it to RegExp
>>> seems like a poorly conceived idea to me...
>>>
>>>> On Jul 20, 2017, at 9:48 PM, Alex Harui <aha...@adobe.com.INVALID
>>>> <mailto:aha...@adobe.com.INVALID <mailto:aha...@adobe.com.INVALID>>> wrote:
>>>>
>>>> I'm confused. Doesn't Yishay's example use syntax that Harbs claimed
>>>> threw an error?
>>>>
>>>> Anyway, I can believe the three steps Harbs listed are correct for JS
>>>> since step 1 might just happen via implicit type coercion. I suppose
>>>> someone could test it by seeing if JS handles "new RegExp({})";
>>>>
>>>> But since there are differences between SWF and JS I want to first make
>>>> sure we have agreement that the goal here is to be backward compatible
>>>> with SWF if we can. I don't think we should be requiring folks to
>>>> modify
>>>> existing passing of strings or getting the compiler to try to modify
>>>> those
>>>> strings if we can figure out how to get match() in JS to be equivalent
>>>> to
>>>> SWF's match().
>>>>
>>>> So I think Herbs suggested wrapping in try catch like this, correct?
>>>>
>>>> public function match(input:String, pattern:*):Array
>>>> {
>>>> COMPILE::SWF
>>>> {
>>>> return input.match(pattern);
>>>> }
>>>> COMPILE::JS
>>>> {
>>>> try
>>>> {
>>>> return input.match(pattern);
>>>> }
>>>> catch (e:Error)
>>>> {
>>>> pattern = pattern.toString();
>>>> if (input.indexOf(pattern) != -1)
>>>> return [ pattern ]; // or whatever should be returned
>>>> return null;
>>>> }
>>>> }
>>>> }
>>>>
>>>> I don't think we should use trace to tell folks not to use String. You
>>>> are welcome to add it to the ASDoc though.
>>>>
>>>> -Alex
>>>>
>>>>
>>>> On 7/20/17, 10:52 AM, "yishayw" <yishayj...@hotmail.com
>>>> <mailto:yishayj...@hotmail.com>
>>>> <mailto:yishayj...@hotmail.com <mailto:yishayj...@hotmail.com>>> wrote:
>>>>
>>>>> I think there would still be a difference between flash and js
>>>>> because the
>>>>> flash implementation (counter to AS3 documentation) always returns
>>>>> null
>>>>> when
>>>>> an invalid regex is passed as a string. So according to your suggested
>>>>> implementation for
>>>>>
>>>>> Var s: String = "m?o";
>>>>> Var a:Array = s.match("?")
>>>>>
>>>>> a is null in flash but ["?"] in JS.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache->
>>>>> fle
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache>
>>>>> -fle>
>>>>> x-development.2333347.n4.nabble.com
>>>>> <http://x-development.2333347.n4.nabble.com/>
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fx-deve
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fx-deve>
>>>>> lopment.2333347.n4.nabble.com
>>>>> <http://lopment.2333347.n4.nabble.com/>%2F&data=02%7C01%7C%7C6ec68d20c01e4fae6173
>>>>> 08d4cfa95280%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363617735199
>>>>> 74472&sdata=UiouHqnKJ4SI1gEcaeu9N5%2FHqGYle%2FKELTCvKRo8c8c%3D&reserved
>>>>> =0>%2FFlexJS-String-match-tp63392p63467.ht
>>>>>
>>>>> ml&data=02%7C01%7C%7C381f79bbe2594b1cab0808d4cf9af1a0%7Cfa7b1b5a7b34438
>>>>> 794
>>>>>
>>>>> aed2c178decee1%7C0%7C0%7C636361711762211281&sdata=gA2I9N%2Bq%2F%2FvILp7
>>>>> C3c
>>>>> UQHenXZDXmu0lK3PtJ%2FnhetW4%3D&reserved=0
>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>> Nabble.com <http://nabble.com/>
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnabble
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnabble>
>>>>> .com%2F&data=02%7C01%7C%7C6ec68d20c01e4fae617308d4cfa95280%7Cfa7b1b5a7b
>>>>> 34438794aed2c178decee1%7C0%7C0%7C636361773519974472&sdata=1Eu83yHYa6TaL
>>>>> rDm0RmuENLfQREVxolgz4%2BbWUgKB9c%3D&reserved=0>.
