156355 - The [[Class]] property of the RegExp prototype

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Phil Schwartau]

From ECMA-262 Edition 3 Final

Section 15.10.6 states:
The value of the internal [[Class]] property of the RegExp prototype 
object is "Object".


We have "RegExp" instead:

js> RegExp.prototype.toString = Object.prototype.toString;
js> RegExp.prototype.toString();
[object RegExp]

Alternatively:

js> Object.prototype.toString.apply(RegExp.prototype);
[object RegExp]


Note: Microsoft does the same thing. Try this javascript:URL in IE6:

javascript: alert(Object.prototype.toString.apply(RegExp.prototype))

Comment 1

[Phil Schwartau]

I've cc'ed Waldemar because I think this may be a bug in the spec.

Section 15.10.6 differs from every other section defining the [[Class]]
of  prototypes. For every other type of object (except "NativeError" objects), 
the prototype of the contructor has the same [[Class]] as an instance.


For example:

15.3.4 Properties of the Function Prototype Object
The Function prototype object is itself a Function object
(its [[Class]] is "Function")


As for the NativeError objects, we have a natural variation:

15.11.7.7 Properties of the NativeError Prototype Objects
Each NativeError prototype object is an Error object
(its [[Class]] is "Error").


My question is, why should the RegExp prototype be treated differently 
from all the others? I checked the Errata for the spec and found nothing 
relevant.

If this is not a typo or bug in the spec, then it might be good for the
spec to at least include a short explanation on why [[Class]] behaves 
differently on |RegExp.prototype| from every other prototype object -

Comment 2

[Brendan Eich [:brendan]]

This had better be a spec bug.

/be

Comment 3

[Waldemar Horwat]

This is not actually a spec bug.  The rationale for making RegExp.prototype have
class Object instead of RegExp is to prevent the regular expression methods from
being called on RegExp.prototype; we at ECMA didn't want to specify what that
would do, and this decision makes it a TypeError to call one of the regular
expression methods on RegExp.prototype according to the last sentence of 15.10.6.

Comment 4

[Phil Schwartau]

Thanks - as a reference, here's what I get on this javascript:URL

     javascript: alert(typeof RegExp.prototype.exec('abc'));


        NN4.7              Mozilla              IE6
     'undefined'         'undefined'          'object'


In IE6, the result is an Array object of length 1, containing the empty
string as its only element. This is the same result one would get from
a new RegExp instance with no pattern. That is, in IE6, these are the same:

                        new RegExp().exec('abc')
                    RegExp.prototype.exec('abc')


Not getting any TypeErrors.


QUESTIONS:

1. Should we correct SpiderMonkey to make it ECMA-conforming on this point,
   or let this one go? 

2. If we do not follow ECMA, then should we conform to IE6 as above?

Comment 5

[Brendan Eich [:brendan]]

waldemar: any chance of changing the standard to codify what IE6 does?  That
would be less of a deviation from all other native class prototypes, and take
less special-case code to implement in SpiderMonkey (at any rate).  It seems to
me it would require no hardship in the spec, either -- the prototype would be a
RegExp created with the empty string as its source.

Patch to emulate IE6 coming up.

/be

Comment 6

[Brendan Eich [:brendan]]

Attachment: proposed IE6-emulating fix

To make RegExp.prototype seem to be of class Object, we would have to either

(a) inline-expand the JS_InitClass call in js_InitRegExpClass, tweaking its
expansion to create in proto a new instance of &js_ObjectClass rather than of
the passed in clasp; or,

(b) factor JS_InitClass into a subroutine, js_InitClassWithDifferentProtoClass,
that takes an additional proto_clasp parameter, passing clasp along in the call
to js_InitClassWithDifferentProtoClass from JS_InitClass, and calling js_ICWDPC
directly from js_InitRegExpClass with &js_ObjectClass passed for proto_clasp,
but &js_RegExpClass passed for clasp.

It could be done, but: Yuck.

/be

Comment 7

[Waldemar Horwat]

I certainly wouldn't recommend going out of our way to make [[Class]] of
RegExp.prototype be "Object" instead of "RegExp" -- it's a minuscule deviation
from the standard.  I recommend marking this bug as WONTFIX.

We only amend ECMA Edition 3 to fix clear errors; this is not an error, so we
won't amend Edition 3 to change this, but we might revisit the issue for the
final JS2 / ECMA Edition 4.

Comment 8

[Brendan Eich [:brendan]]

Suits me -- thanks,

/be

Comment 9

[Phil Schwartau]

Marking Verified -

Comment 10

[rogerl (gone)]

[Tentatively] - Are we not going to consider IE6 compatibilty by applying the
patch, then?

Comment 11

[Brendan Eich [:brendan]]

D'oh!  Thanks, rogerl.  What do you think of that patch?  r= it if it seems
good; I'm in favor of IE6 compatibility, and maybe shaver is too.

/be

Comment 12

[rogerl (gone)]

Comment on attachment 90725 [details] [diff] [review]
proposed IE6-emulating fix

r=rogerl

Comment 13

[Mike Shaver (:shaver emeritus)]

Comment on attachment 90725 [details] [diff] [review]
proposed IE6-emulating fix

sr=shaver.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 90725 [details] [diff] [review]
proposed IE6-emulating fix

Approving for trunk checkin during the 1.1beta trunk closure.

Comment 15

[Brendan Eich [:brendan]]

Checked into the trunk.  Still pining for branch approval.

/be

Comment 16

[Brendan Eich [:brendan]]

dbaron wanted some trunk baking before approving for the branch.

/be

Comment 17

[Phil Schwartau]

2002-07-11: patch landed on trunk in CVS
2002-07-20: patch landed on -rMOZILLA_1_0_BRANCH in CVS

(Thanks, Brendan!)


I can confirm that on both trunk and branch, we are now emulating
IE6 on the point raised in Comment #4. That is, the result of 

                RegExp.prototype.exec('abc')

is an Array object of length 1, containing the empty string
as its only element. This is the same result one would get
from a new RegExp instance with no pattern. In other words,
these are now the same:

                    new RegExp().exec('abc')
                RegExp.prototype.exec('abc')


Not getting any TypeErrors; ready to mark this bug verified
once it is marked fixed -

Comment 18

[Brendan Eich [:brendan]]

Oops, forgot to close when I checked into the branch.

/be

Comment 19

[Phil Schwartau]

Marking Verified Fixed; adding fixed1.0.1, verified1.0.1 keywords -