Identifying a regex

[Stefan Weiss]

What do you think is the best way to identify a value as a regular
expression (reference to a RegExp object)? I can see at least four
different ways, each with its own drawbacks:

A) val instanceof RegExp
B) val.constructor.name == "RegExp"
C) Object.prototype.toString.call(val) == "[object RegExp]"
D) duck typing


A selection of possible error sources:

A) Has problems when the regex object was created in a different window
(frame) from where it's being analyzed.

B) The constructor property can be changed manually at any time.

C) I've seen mention of failures in IE when the regex is created in
another window (frame). Theoretically, a badly designed host object
could also have an internal [[Class]] of "RegExp" and still be compliant
with the standard, which only covers the [[Class]] names of native objects.

D) It's probably a duck, but it might be a confused goose.


I'm currently favoring option (B). The way I see it, if somebody messes
around with the constructor property of a native object for no good
reason, they're voiding their warranty. In addition, this test is not
intended to be part of a general purpose library, which means that the
number of potentially misbehaving users is very limited.

Option (C) also looks promising, if the IE problem only affects older
versions. Unfortunately, I can't test this, because my memory is maxed
again and I can't launch any more VMs. I seriously need to upgrade...

Looking forward to your thoughts about this.

- stefan

[Michael Haufe (TNO)]

Assuming you want to avoid a combination of the above techniques,
regular expressions also have a 'source' property that cannot be
changed directly. So...

function isRe(re){
var s = re.source
re.source = s + "foo"
var p = (s == re.source)
if(!p) re.source = s //restore just in case
return p
}

Of course then you'll have to worry about ES5 lockdown features...

[JJ]

On Mon, 17 Jun 2013 01:47:53 +0200, Stefan Weiss wrote:
> What do you think is the best way to identify a value as a regular
> expression (reference to a RegExp object)? I can see at least four
> different ways, each with its own drawbacks:
>
> A) val instanceof RegExp
> B) val.constructor.name == "RegExp"
> C) Object.prototype.toString.call(val) == "[object RegExp]"
> D) duck typing

I've been using this kind of duck. Does it have a defect?

isNativeCode = /\{[ \n]+\[native code\][ \n]+\}$/im;
isRegExp = (val instanceof RegExp) &&
isNativeCode.test(RegExp) && isNativeCode.test(RegExp.toString);

[Stefan Weiss]

On 2013-06-17 04:30, Michael Haufe (TNO) wrote:
> On Jun 16, 6:47 pm, Stefan Weiss <krewech...@gmail.com> wrote:
>> What do you think is the best way to identify a value as a regular

>> expression (reference to a RegExp object)? [...]
...

> Assuming you want to avoid a combination of the above techniques,
> regular expressions also have a 'source' property that cannot be
> changed directly. So...

I'm not sure if a combination of techniques would help. Wouldn't both
the false positives and false negatives just add up?

> function isRe(re){
> var s = re.source
> re.source = s + "foo"
> var p = (s == re.source)
> if(!p) re.source = s //restore just in case
> return p
> }

That's duck typing (of a sort), but more invasive than usual. For
example, when you call this function with a plain empty object ({}), it
will have a "source" property afterwards. It's also not safe to assume
that changing a property to a new value and then changing it back will
restore the object to its original state. And lastly, there are valid
reasons to create other (non-regex) objects with an immutable "source"
property.


- stefan

[Stefan Weiss]

I don't understand what you're doing here...

The first test (val instanceof RegExp) is the method (A) I mentioned
earlier, and it will suffer from the same problem (cross-frame
identification).
The other tests just check the native RegExp object, not the value.


- stefan

[Michael Haufe (TNO)]

With the language being as fast and loose as it is, (plus proxies now
and interactions between differing versions of the language in the
same document), you're just about shit out of luck I think for a 100%
guarantee on identity and capability for objects you don't control.
Any test (or combination thereof) will be little more than
probabilistic test. Using the constructor property can also be
considered a duck-typing check. In the past I've espoused instanceof
strongly over other methods if you might recall. You could simply
follow the Self/SmallTalk tradition and simply act as if it WAS a
RegExp until it explodes...

[Thomas 'PointedEars' Lahn]

Michael Haufe (TNO) wrote:

> With the language being as fast and loose as it is, (plus proxies now
> and interactions between differing versions of the language in the
> same document), you're just about shit out of luck I think for a 100%
> guarantee on identity and capability for objects you don't control.
> Any test (or combination thereof) will be little more than
> probabilistic test. Using the constructor property can also be
> considered a duck-typing check.

I do not see a reason why the “constructor” property value should be mutable
in the first place. If it were not, it could at least provide for efficient
tests where neither inheritance nor frame safety were issues.

> In the past I've espoused instanceof strongly over other methods if you
> might recall. You could simply follow the Self/SmallTalk tradition and
> simply act as if it WAS a RegExp until it explodes...

My thoughts exactly. In languages as dynamic as ECMAScript implementations
it is a mistake _not_ to delegate at least a part of the responsibility for
proper input to the caller (do I need to cite evidence for the bloat created
by following the opposite approach?). Not only would that be more likely to
produce false negatives, it would also miss the opportunity to make use of
language power and elegance.

In the case of references to RegExp instances, though, where inheriting from
their prototype does not make sense and so all pertinent objects have
[[Class]] "RegExp", in JSX:regexp.js I have switched from comparison against
the “constructor” property value to jsx.object.getClass() for the next
revision, for cross-view referencing.

It is unfortunate that almost everything in ECMAScript hinges on the Global
Object of an execution context, that there are several global execution
contexts, and that thereby the Specification forces its conforming
implementations to be in such a way that methods like Array.isArray() are
needed for the classification of objects in the first place. It should not
be necessary to have several RegExp objects just because there are several
views (frames, windows, tabs).

A quick solution would be if there was a superglobal object that all native
objects had in their prototype chain, or all global execution contexts had
in their scope chain, so that “foo instanceof RegExp” would work regardless
of callee and caller views as long as they were of the Same Origin. The
global object of execution contexts would then only have properties specific
to that execution context and would delegate everything else to the
superglobal object.

--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[JJ]

On Mon, 17 Jun 2013 14:11:31 +0200, Stefan Weiss wrote:
> I don't understand what you're doing here...
>
> The first test (val instanceof RegExp) is the method (A) I mentioned
> earlier, and it will suffer from the same problem (cross-frame
> identification).
> The other tests just check the native RegExp object, not the value.

Assuming RegExp has not been modified in both windows, shouldn't this be
true?

window1.RegExp === window2.RegExp

[Michael Haufe (TNO)]

On Jun 17, 6:16 pm, "Michael Haufe (TNO)" <t...@thenewobjective.com>
wrote:

Looks like you weren't in the older conversation this topic, so here
is probably the most explicit thread reflecting my current opinion on
the topic of instanceof. Of course I'm a bit bipolar on this as I'm an
extreme fan of esoteric typed programming languages, yet I grew up
using JS...

<https://groups.google.com/group/jsmentors/browse_thread/thread/
d77e41c69c283ceb/3b99a7dc60be2052>

[Thomas 'PointedEars' Lahn]

Michael Haufe (TNO) wrote:

> Looks like you weren't in the older conversation this topic, so here
> is probably the most explicit thread reflecting my current opinion on
> the topic of instanceof. Of course I'm a bit bipolar on this as I'm an
> extreme fan of esoteric typed programming languages, yet I grew up
> using JS...
>
> <https://groups.google.com/group/jsmentors/browse_thread/thread/
> d77e41c69c283ceb/3b99a7dc60be2052>

The number of misconceptions about the languages that can be found by
scanning that thread alone, and that one would have to unlearn to arrive at
the truth is, for lack of words, fascinating. There are statements there
ranging from that “Javascript” were not *an* OOL at all, that there was
something special like “Object-oriented Javascript” that needed to be added;
that *it* was not JIT-compiled but interpreted; that either the way of
inheritance or compilation had anything to do with the level of a
programming language; that *it* was “a little OO” because *it* “has features
of OO”, that you should not use “new”, “this”, and constructors, and so on.

Observing this, one must truly wonder how these people, including you
unfortunately, can ever get anything done in this field. I think it is fair
to say that at this point “JSMentors” should be renamed to “JSWannabes”.

Your opinion (or shall I say “your misconception”?) is on page 3 of that
thread here. You should have referred to it directly, but then again you
would have deprived me of the experience.

For how class-based inheritance can be properly and rather easily emulated,
look into Function.prototype.extend() in JSX:object.js, and for how that can
be put to good use look into other parts of JSX, for example
JSX:dom/widgets.js.

HTH

[Stefan Weiss]

On 2013-06-18 02:13, Thomas 'PointedEars' Lahn wrote:

> Michael Haufe (TNO) wrote:
>> In the past I've espoused instanceof strongly over other methods if you
>> might recall. You could simply follow the Self/SmallTalk tradition and
>> simply act as if it WAS a RegExp until it explodes...
>
> My thoughts exactly. In languages as dynamic as ECMAScript implementations
> it is a mistake _not_ to delegate at least a part of the responsibility for
> proper input to the caller

That's a good general guideline; I normally treat function arguments
this way. In some unusual cases, it may still be necessary to identify
the exact type of a value (e.g., in debugging aids).

> In the case of references to RegExp instances, though, where inheriting from
> their prototype does not make sense and so all pertinent objects have
> [[Class]] "RegExp", in JSX:regexp.js I have switched from comparison against
> the “constructor” property value to jsx.object.getClass() for the next
> revision, for cross-view referencing.

For reference:

var _getClass = (function () {
var _toString = ({}).toString;

return function (obj) {
return (_toString.call(obj)
.match(/^\s*\[object\s+(\S+)\s*\]\s*$/) || [, ])[1];
};
}());

http://pointedears.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fobject.js

That would correspond to option (C) in my original question.

The old comparison method in your regexp.js (rev 361) is not the same as
option (B), however: comparing the constructor property directly with
RegExp does not work across frames, but comparing constructor.name with
"RegExp" does (as long as nobody messed with the constructor directly).

In my specific case, I can see both methods working equally well.
Parsing the internal [[Class]] name would be safer in a general purpose
library, and having a generic getClass() method will also be useful
elsewhere. On the other hand, a direct string comparison with
constructor.name is much faster than the regex-based identification:
approximately 3-4x faster in Chrome, 25x in Opera, and about 50x in
Firefox (usual benchmark caveats apply). Both methods perform well
enough, so the speed difference can probably be ignored for typical usage.

That still leaves the question about a potential problem in IE, which
I've seen mentioned but can't confirm at the moment:

http://stackoverflow.com/questions/4339288/typeof-for-regexp#comment4726148_4339385


- stefan

[Stefan Weiss]

On 2013-06-18 07:46, JJ wrote:
> Assuming RegExp has not been modified in both windows, shouldn't this be
> true?
>
> window1.RegExp === window2.RegExp

No, this evaluates to false (unless window1 == window2).

- stefan

[Andreas Bergmaier]

Stefan Weiss schrieb:

> What do you think is the best way to identify a value as a regular
> expression (reference to a RegExp object)? I can see at least four
> different ways, each with its own drawbacks:
>

> […]
> B) val.constructor.name == "RegExp"
> […]

> The constructor property can be changed manually at any time.

The bigger drawback I see is that `name` is a non-standard property.
Most notably, it doesn't exist in Internet Explorer.

The only workaround I could find seems to be parsing it out of the
.toString() representation, which again does not work in all environments.

Bergi

[Thomas 'PointedEars' Lahn]

Stefan Weiss wrote:

> On 2013-06-18 02:13, Thomas 'PointedEars' Lahn wrote:
>> In the case of references to RegExp instances, though, where inheriting
>> from their prototype does not make sense and so all pertinent objects
>> have [[Class]] "RegExp", in JSX:regexp.js I have switched from comparison
>> [[against the “constructor” property value to jsx.object.getClass() for
>> the next revision, for cross-view referencing.
>
> For reference:
>
> var _getClass = (function () {
> var _toString = ({}).toString;
>
> return function (obj) {
> return (_toString.call(obj)
> .match(/^\s*\[object\s+(\S+)\s*\]\s*$/) || [, ])[1];
> };
> }());
>
>
http://pointedears.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fobject.js
>
> That would correspond to option (C) in my original question.

Yes.

> The old comparison method in your regexp.js (rev 361) is not the same as
> option (B), however: comparing the constructor property directly with
> RegExp does not work across frames, but comparing constructor.name with
> "RegExp" does (as long as nobody messed with the constructor directly).

I am not convinced that constructor.name is interoperable in the first
place. The ECMAScript Support Matrix, Version 2, contains a testcase for
Function.prototype.name that has been recently run (by someone else – thank
you) to fail in JavaScript 1.8.6 and JScript 10.0.16578. But that might be
due to “name” being a property of Function instances only in those
implementations. I shall modify that testcase accordingly.

<http://PointedEars.de/es-matrix/?filter=Function.prototype.name#features-table>

That said, neither Function.prototype.name nor functionInstance.name are
specified in the ECMAScript Language Specification, 5.1 Edition, §15.3, so
they are very likely not interoperable. Which is why there is

/**
* Returns the name of a function
*
* @param {Function|String} aFunction
* @return {string}
* The name of a function if it has one; the empty string otherwise.
*/
jsx.object.getFunctionName = function (aFunction) {
/* Return the empty string for null or undefined */
return (aFunction != null
&& typeof aFunction.name != "undefined" && aFunction.name)
|| (String(aFunction).match(/\s*function\s+([A-Za-z_]\w*)/) || [, ""])
[1];
};

> In my specific case, I can see both methods working equally well. […]

I don't.

[Stefan Weiss]

On 2013-06-18 21:39, Thomas 'PointedEars' Lahn wrote:

> Stefan Weiss wrote:
>> The old comparison method in your regexp.js (rev 361) is not the same as
>> option (B), however: comparing the constructor property directly with
>> RegExp does not work across frames, but comparing constructor.name with
>> "RegExp" does (as long as nobody messed with the constructor directly).
>
> I am not convinced that constructor.name is interoperable in the first
> place. The ECMAScript Support Matrix, Version 2, contains a testcase for
> Function.prototype.name that has been recently run (by someone else – thank
> you) to fail in JavaScript 1.8.6 and JScript 10.0.16578. But that might be
> due to “name” being a property of Function instances only in those
> implementations. I shall modify that testcase accordingly.
>
> <http://PointedEars.de/es-matrix/?filter=Function.prototype.name#features-table>
>
> That said, neither Function.prototype.name nor functionInstance.name are
> specified in the ECMAScript Language Specification, 5.1 Edition, §15.3, so
> they are very likely not interoperable.

Good point (also made by Andreas Bergmaier earlier in the thread).
That's enough to disqualify this option.

Unfortunately, the test using Object.prototype.toString is not
completely interoperable, either. In IE8, it works as expected across
iframes (and regular old-fashioned frames). Across windows, it returns
"[object Object]" instead of "[object RegExp]". The same applies to
other types (function, array, date).

A simple test page:

http://foo.at/paste/2013/test_re.html

I currently have no way of testing this with more recent versions of IE,
but would be interested in the results.


- stefan

[Michael Haufe (TNO)]

On Tuesday, June 18, 2013 3:39:28 AM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> > Looks like you weren't in the older conversation this topic, so here
> > is probably the most explicit thread reflecting my current opinion on
> > the topic of instanceof. Of course I'm a bit bipolar on this as I'm an
> > extreme fan of esoteric typed programming languages, yet I grew up
> > using JS...
> >
>
> > <https://groups.google.com/group/jsmentors/browse_thread/thread/
> > d77e41c69c283ceb/3b99a7dc60be2052>
>
> The number of misconceptions about the languages that can be found by
> scanning that thread alone, and that one would have to unlearn to arrive at
> the truth is, for lack of words, fascinating. There are statements there
> ranging from that “Javascript” were not *an* OOL at all, that there was
> something special like “Object-oriented Javascript” that needed to be added;
> that *it* was not JIT-compiled but interpreted; that either the way of
> inheritance or compilation had anything to do with the level of a
> programming language; that *it* was “a little OO” because *it* “has features
> of OO”, that you should not use “new”, “this”, and constructors, and so on.

> Observing this, one must truly wonder how these people, including you
> unfortunately, can ever get anything done in this field.

We were all just waiting on you Prometheus to bring us your stolen gift from Olympus.

> Your opinion (or shall I say “your misconception”?) is on page 3 of that
> thread here. You should have referred to it directly, but then again you
> would have deprived me of the experience.

If I haven't spread misery every day, I don't feel complete of course.

Mind being more discrete? My comment:

"I'm against 'new' because I believe it should be a bound method of the
object"

I'd like to generalize to: "I'm against 'new' because I believe an object should be responsible for creating its own copies"

If you are referring to the "namespacing". I've abandoned this as not worth pursuing.

OOP based on the definition of TAPL I still follow. I suspect you are probably pointing at some English grammar aspect. This wouldn't be the first time...

> For how class-based inheritance can be properly and rather easily emulated,
> look into Function.prototype.extend() in JSX:object.js, and for how that can
> be put to good use look into other parts of JSX, for example
> JSX:dom/widgets.js.

Yes I've seen and used similar before...

*Apologies in advance if there is some formatting craziness or other issue with this response as I've now officially been forced into the new Google Groups layout...

[Thomas 'PointedEars' Lahn]

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Observing this, one must truly wonder how these people, including you
>> unfortunately, can ever get anything done in this field.
>
> We were all just waiting on you Prometheus to bring us your stolen gift
> from Olympus.

Correcting the misconceptions of wannabes (there) looks like a job for a
lifetime. I have better things to do. You can read my articles here and in
de.comp.lang.javascript, the ES Matrix, and my thesis instead. And read
reference material, written by people who actually *specified* or actually
*built* an ECMAScript implementation.

>> Your opinion (or shall I say “your misconception”?) is on page 3 of that
>> thread here. You should have referred to it directly, but then again you
>> would have deprived me of the experience.
>
> If I haven't spread misery every day, I don't feel complete of course.
>
> Mind being more discrete? My comment:
>
> "I'm against 'new' because I believe it should be a bound method of the
> object"
>
> I'd like to generalize to: "I'm against 'new' because I believe an object
> should be responsible for creating its own copies"
>
> If you are referring to the "namespacing". I've abandoned this as not
> worth pursuing.
>
> OOP based on the definition of TAPL I still follow. I suspect you are
> probably pointing at some English grammar aspect. This wouldn't be the
> first time...

Do you think that such talk will effect my going into details?

> *Apologies in advance if there is some formatting craziness or other issue
> with this response as I've now officially been forced into the new Google
> Groups layout...

You still have the choice of not using Google Groups for posting at all.

[Michael Haufe (TNO)]

On Jun 19, 7:05 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> Michael Haufe (TNO) wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Observing this, one must truly wonder how these people, including you
> >> unfortunately, can ever get anything done in this field.
>
> > We were all just waiting on you Prometheus to bring us your stolen gift
> > from Olympus.
>
> Correcting the misconceptions of wannabes (there) looks like a job for a
> lifetime.  I have better things to do.

Your history in this group and recent efforts seem to belie this.

> You can read my articles here and in
> de.comp.lang.javascript, the ES Matrix, and my thesis instead.  And read
> reference material, written by people who actually *specified* or actually
> *built* an ECMAScript implementation.

Can of course, but probably wont as I also have better things to do
than read through an overlong, non-specific list of resources to
_possibly_ identify a misconception that _possibly_ exists of mine
"[somewhere] on page 3"

[...]

> Do you think that such talk will effect my going into details?

You seem to portray yourself as plenty affected already.

[Thomas 'PointedEars' Lahn]

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> Observing this, one must truly wonder how these people, including you
>> >> unfortunately, can ever get anything done in this field.
>> >
>> > We were all just waiting on you Prometheus to bring us your stolen gift
>> > from Olympus.
>>
>> Correcting the misconceptions of wannabes (there) looks like a job for a
>> lifetime. I have better things to do.
>
> Your history in this group and recent efforts seem to belie this.

No, correcting on occasion the misconceptions of, and in general helping,
people who are (apparently) making an effort to understand and learn, is
something entirely different, and worthwhile.

>> You can read my articles here and in de.comp.lang.javascript, the ES
>> Matrix, and my thesis instead. And read reference material, written by
>> people who actually *specified* or actually *built* an ECMAScript
>> implementation.
>
> Can of course, but probably wont as I also have better things to do
> than read through an overlong, non-specific list of resources to
> _possibly_ identify a misconception that _possibly_ exists of mine
> "[somewhere] on page 3"

My thesis at least is very specific. But this paragraph did not refer to
your misconceptions specifically.

> [...]
>> Do you think that such talk will effect my going into details?
>
> You seem to portray yourself as plenty affected already.

"effect" !== "affect"

[Michael Haufe (TNO)]

Thomas 'PointedEars' Lahn wrote:
> No, correcting on occasion the misconceptions of, and in general helping,
> people who are (apparently) making an effort to understand and learn, is
> something entirely different, and worthwhile.

Fair enough.

Michael Haufe (TNO) wrote:
> Can of course, but probably wont as I also have better things to do
> than read through an overlong, non-specific list of resources to
> _possibly_ identify a misconception that _possibly_ exists of mine
> "[somewhere] on page 3"

Thomas 'PointedEars' Lahn wrote:
> My thesis at least is very specific. But this paragraph did not refer to
> your misconceptions specifically.

Alleged misconceptions... No doubt we'll revisit this topic again in the future. I'd prefer to no longer derail the current thread.

Michael Haufe (TNO) wrote:
> You seem to portray yourself as plenty affected already.

Thomas 'PointedEars' Lahn wrote:
> "effect" !== "affect"

I think we both know what I was implying with my purposeful word abuse. At least you chose a neutral response.

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> I am not convinced that constructor.name is interoperable in the first
> place. The ECMAScript Support Matrix, Version 2, contains a testcase for
> Function.prototype.name that has been recently run (by someone else –
> thank you) to fail in JavaScript 1.8.6 and JScript 10.0.16578. But that
> might be due to “name” being a property of Function instances only in
> those implementations. I shall modify that testcase accordingly.
>
> <http://PointedEars.de/es-matrix/?filter=Function.prototype.name#features-table>

[x] done

> That said, neither Function.prototype.name nor functionInstance.name are
> specified in the ECMAScript Language Specification, 5.1 Edition, §15.3, so

> they are very likely not interoperable. […]

Looking forward to test results to find out.

[Stefan Weiss]

On 2013-06-18 23:58, Stefan Weiss wrote:
> Unfortunately, the test using Object.prototype.toString is not
> completely interoperable, either. In IE8, it works as expected across
> iframes (and regular old-fashioned frames). Across windows, it returns
> "[object Object]" instead of "[object RegExp]". The same applies to
> other types (function, array, date).
>
> A simple test page:
>
> http://foo.at/paste/2013/test_re.html
>
> I currently have no way of testing this with more recent versions of IE,
> but would be interested in the results.

Short follow-up: this bug is fixed in IE10. I still couldn't get hold of
a real IE9, but IE10 with x-ua-compatible set to IE=9 also works (not
sure if that means anything).

- stefan

[Michael Haufe (TNO)]

IE9:

iframe: [object RegExp]
iframe: [object Function]
iframe: [object Array]
iframe: [object Date]
window: [object Object]
window: [object Object]
window: [object Object]
window: [object Object]

[Stefan Weiss]

Thanks for testing.

It seems there is no silver bullet for detecting regex objects. In my
case, I will go with the Object.prototype.toString check anyway, because
I only have to support IE10+ (lucky me).

- stefan