Discuss
  • RegExp.prototype.compile and RegExp instance properties

RegExp.prototype.compile and RegExp instance properties

# Allen Wirfs-Brock (13 years ago)

We've previously concluded that RegExp.prototype.compile is part of web reality and should be included in the ES6 spec. Whether it is put in the main spec. or in Annex B doesn't make a difference for the technical issue I'm about to discuss.

Currently RegExp instances are specified to have four own data properties (source, global, ignoreCase, multiline) that are non-writable and non-configurable.

This is fine because the standard spec. for RegExp initializes these properties when the object is constructed and according to the spec. they never change.

However, RegExp.prototype.compile, as widely implemented in browsers allows the pattern and flags associated with an RegExp instance to be modified after object construction is completed and changing the pattern/flags also changes the values of these four properties. Implementation just change their values even though the properties are non-writable/non-configurable.

If we are going to include the compile method in the spec. we need to do so without violating the invariant that a non-configurable/non-writable property never changes its visible value. There are several ways we might do this:

  1. Change the specified attributes of these properties to {writable: false, configurable: true} or perhaps {writable: true, configurable: false}. However, if we want to enforce that the only way to modify them was via the compile method we would have to make RegExp instances a special kind of exotic object in order to prevent assignment or Object.defineProperty from being used to modify the values of the property.

Compatibility impact: change of property attribute from ES5 Spec/implementation impact: requires introduction of a new kind of exotic object

  1. Change these properties to instance own accessor properties with a get function but no set function. The accessors would produce values based upon the current pattern and flags.

Compatibility impact: visibly changes the properties from data properties to accessor properties.
Spec./implementation issues: Do all instances share the same get functions or do 4 new get function need to be created for every RegExp instance? (Observable via get function identify)

  1. Change these properties to prototype level accessor get-only accessor properties

Compatibility impact: visible change from data to accessor property. Inherited prototype property rather than instance property. Inherited property could be over-ridden at instance level.

.#3 is similar to how WebIDL now represents similar properties. It is probably the easiest to spec. and implement. It is the biggest change from a compat. perspective but I suspect that the actual compat. impact of any of these is small. If I was designing RegExp from scratch and still had these requirements I would probably go with #3.

What do people think? #3 or #2? I really don't want to go the exotic object route.

# Brendan Eich (13 years ago)

.#3. If any ES5 or lookupGetter code breaks, I'll be surprised, but also willing to say "too bad".

# Mark S. Miller (13 years ago)

My answer depends on a prior issue. Do we agree that in ES6, RegExp.prototype is not itself a RegExp? Like the Date.prototype and WeakMap.prototype we've already talked about, freezing it and everything reachable from it must render it immutable, so that it isn't a communications channel. SES currently removes RegExp.prototype.compile to prevent that communications channel. SES includes all variables, properties, and methods normatively defined by ES5. I would really like to see it include all of normative ES6 without violating ocap rules.

If we agree that RegExp.prototype is not a RegExp and the invariant breakage of compile were fixed by any of your proposals, then I believe we would no longer need to remove it.

Although any of your proposals will then work, I'll suggest a variation of your least favorite (#1):

.#4: These properties are {writable: false, configurable: true}. RegExps may indeed need to be exotic. But they don't refuse freezing. Rather, if a RegExp is frozen, or if its properties are individually made non-configurable non-writable, then neither compile nor anything else can mutate that RegExp. A frozen RegExp (without additional properties) is an immutable RegExp. This would be pleasant.

# Brendan Eich (13 years ago)

Mark S. Miller wrote:

My answer depends on a prior issue. Do we agree that in ES6, RegExp.prototype is not itself a RegExp?

Yes, we agreed to that for all the built-ins:

esdiscuss/2012-September/025301 (thread head)

esdiscuss/2012-October/025432 (my proposal)

bugzilla.mozilla.org/show_bug.cgi?id=797686 (bugzilla bug I need to go patch!)

# Mark S. Miller (13 years ago)

Thanks. That's what I thought, but wanted to be sure.

In that case, I have no objections to any of these proposals, but I prefer #4.

# Allen Wirfs-Brock (13 years ago)

On Jan 15, 2013, at 6:10 PM, Mark S. Miller wrote:

Thanks. That's what I thought, but wanted to be sure.

In that case, I have no objections to any of these proposals, but I prefer #4.

I really think whenever possible we should be prefer designs that require or introduce new kinds of exotic objects.

However, I'd be happy to spec. RegExp compile such that it refuses to change any RegExp object that is non-extensible. Would that make like easier for SES? Again, it's unlike that this will actually break anything.

Given, that I'd still think #3 is the best choice.

# Mark S. Miller (13 years ago)

On Tue, Jan 15, 2013 at 6:21 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

On Jan 15, 2013, at 6:10 PM, Mark S. Miller wrote:

Thanks. That's what I thought, but wanted to be sure.

In that case, I have no objections to any of these proposals, but I prefer #4.

I really think whenever possible we should be prefer designs that require or introduce new kinds of exotic objects.

However, I'd be happy to spec. RegExp compile such that it refuses to change any RegExp object that is non-extensible. Would that make like easier for SES?

Yes. As far as I'm concerned, that is as good as #4.