-
Notifications
You must be signed in to change notification settings - Fork 21
Investigate need for reflection/genericity over groups #12
Comments
Some thoughts: const { a, b, c } = match.groups; // if it's always an object
const { a, b, c } = match.groups || {}; // if it's absent when there's no matches
const { groups: { a, b, c } } = match; // if it's always an object
const { groups: { a, b, c } = {} } = match; // if it's absent when there's no matches One possibly performant way we could make it always be an object is, instead of making {
enumerable: true,
configurable: true,
get() {
if (!this.[[matchedGroups]]) { // internal slot
this.[[matchedGroups]] = {};
}
return this.[[matchedGroups]];
},
set(value) {
Object.defineProperty(this, 'groups', { enumerable: true, configurable: true, value, writable: true });
}
} However, given that |
From an efficiency point of view, I'd still argue for keeping the groups object as a plain JS object with named captures added as data properties by RegExpBuiltinExec (i.e. the current proposal). The object should be added only when the RegExp contains named captures. In V8, RegExpResult creation (as well as other RegExp glue code) is now done in CodeStubAssembler, which means we're limited in what we can do without bailing out to (slow) runtime. For instance, we can efficiently construct objects from existing maps, but map manipulations (such as adding accessors at runtime) have to be done in C++. Additional advantages of using a plain JS object with properties:
Disadvantages:
Implementation-wise, a 'group(name)' getter installed on the result object itself which references an internal name-string map is probably more efficient, but also less convenient for users. |
More context on the previous post: this was in response to an offline discussion about different possibilities of exposing named captures on the result object. Some of these were:
The previous reply argues for the last option. |
At the January 2017 TC39 meeting, we discussed some other properties that we might like to have from the
|
@littledan the resolution from the first bullet implies that all named groups will be present on the object, which makes sense to me. Does the second imply that there will be an unconditional unfrozen |
That it will only be created on match objects when the RegExp had named groups. The quoted section could be rephrased to, "If we added the groups..." |
Sounds good. |
Is there any concern over behavior ambiguity where the What if a named group property name is attempted to be added to Wouldn't it be simpler if the |
I agree about the proto of groups. Actually, it already is null, see https://tc39.github.io/proposal-regexp-named-groups/#sec-regexpbuiltinexec |
Raised in various ways by @bterlson and @ljharb at the January 2017 TC39 presentation.
The text was updated successfully, but these errors were encountered: