W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2012

Re: RegExp support in WebIDL

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Thu, 5 Jul 2012 07:34:27 +0000
Message-ID: <CABZUbM0ynCsty=1jOswxwfzdmxY48nk3J9a-d90o-fV2L8NDmg@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: public-script-coord@w3.org
On 7/4/12, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> Hi,
>    WebIDL currently doesn't support RegExp values.  However, we are
> working on a feature for Opera's extensions where the ability to set a
> value of a dictionary property to a regular expression would be useful.
> I believe most other built-in ECMAScript objects can be represented in
> WebIDL.  RegExp seems to be the only built-in ES5 object that can't.
> Our use case is for a dictionary that looks something like this:
> dictionary Properties {
>    (DOMString or RegExp) pattern
>    ...
> }
> When it's the value is set to a DOMString, the match is a simple keyword
> match. When it's a regular expression, it can handle more complicated
> pattern matching.
> Possible solutions we could use given the current state of the spec are
> to either:
> 1. Use (DOMString or object) and then handle evaluating it as a
>     regular expression in prose.
> 2. Define the pattern as a DOMString only, which when set to an ES
>     RegExp value, will stringify as "/.../" and can then be parsed
>     again. This would require carfully differentiating between strings
>     intended for keyword matches and strings intended to be regular
>     expressions.
String.prototype.search does it the other way around.

| If Type(regexp) is Object and the value of the [[Class]] internal
| property of regexp is "RegExp", then let rx be regexp;
| Else, let rx be a new RegExp object created as if by the expression
| new RegExp(regexp) where RegExp is the standard built-in
| constructor with that name.

The RegExp constructor will call ToString on the pattern arg passed.

Not sure if this matters at all...
Twitter: @xkit
Received on Thursday, 5 July 2012 07:34:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:07 UTC