Conversation
a5f64ef to
ab4433a
Compare
ab4433a to
86349af
Compare
| You cannot change this property directly. It is read-only. | ||
| - Any [Unicode codepoint escapes](/en-US/docs/Web/JavaScript/Guide/Regular_Expressions/Unicode_Property_Escapes) (`\u{xxxx}`, `\p{UnicodePropertyValue}`) will be interpreted as such instead of literal characters. | ||
| - Surrogate pairs will be interpreted as whole characters instead of two separate characters. For example, `/[😄]/u` would only match `"😄"` but not `"\ud83d"`. | ||
| - When [`lastIndex`](/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/lastIndex) is automatically advanced (such as when calling [`exec()`](/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/exec)), unicode regexps advance by Unicode codepoints instead of UTF-16 code units. |
There was a problem hiding this comment.
Hmm, I'd think that a warning about the mismatch between JavaScript string indexing with brackets vs. the index returned here, might be warranted?
There was a problem hiding this comment.
lastIndex still returns the UTF-16 index. It just may advance by 2 in case of a surrogate pair.
| @@ -1,5 +1,5 @@ | |||
| --- | |||
| title: RegExp.prototype.sticky | |||
| title: get RegExp.prototype.sticky | |||
There was a problem hiding this comment.
Ooh, I have not seen get used in any MDN titles yet... isn't such an introduction pending the discussion about prototype accessors vs own properties?
There was a problem hiding this comment.
No, get is already used in @@species. I think it makes sense to update these.
There was a problem hiding this comment.
Was that broadly agreed in @@species or did it just just sneak in?
I have no care factor about what syntax we use, but it shouldn't appear by magic - it should be discussed (and not just in one PR). If agreed it should be updated in the contributor docs so that we're all on the same page. IN addition, we should identify all the cases that need updating and do them as a project.
If there was extensive discussion and this is all documented and well understood. Apologies. Don't know how I missed it.
I made a similar comment above - just linking so no need to respond in both places #19540 (comment)
There was a problem hiding this comment.
@@species seems to just have been like that from the start. Plus we just don't have an agreed-upon notation for any property. (cf mdn/mdn-community#153) I guess @@species was written like that because these pages are so niche that no one cares about them other than spec gurus :-)
I really don't have strong opinions about whether we prefix getter-only properties with get, but this seems like a really low-bar change compared to marking up instance properties. If others feel like the change is too bold I can revert it for now.
| ## Description | ||
|
|
||
| The value of `sticky` is a {{jsxref("Boolean")}} and true if the `y` flag was used; otherwise, false. The `y` flag indicates that it matches only from the index indicated by the {{jsxref("RegExp.lastIndex", "lastIndex")}} property of this regular expression in the target string (and does not attempt to match from any later indexes). A regular expression defined as both `sticky` and `global` ignores the `global` flag. | ||
| `RegExp.prototype.sticky` is a getter-only property that returns `true` if the `y` flag was used; otherwise, `false`. The `y` flag indicates that it matches only from the index indicated by the {{jsxref("RegExp.lastIndex", "lastIndex")}} property of this regular expression in the target string (and does not attempt to match from any later indexes). |
There was a problem hiding this comment.
I suspect that the term "getter-only" may not be friendly towards beginners. Any thoughts on this?
There was a problem hiding this comment.
The fact that no-one complains up till now probably means these pages are non-starter from the beginning, so I guess it's fine. Most would read the guide anyway.
There was a problem hiding this comment.
How is "getter-only" different from read-only? i.e. it is far more common to see something like:
The
RegExp.prototype.stickyis a read-only property returnstrue...
And in the parent doc you'd have the {{readonly_inline}} macro
There was a problem hiding this comment.
Not much. "Read-only" is for data properties, "getter-only" is for accessor properties; but when you use them they are pretty much interchangeable.
There was a problem hiding this comment.
I'm just not sure it is a useful distinction. If it isn't, then better to make things consistent. If it is, then great - but we need to agree how and document that approach.
Edited. I see this has been added to the discussion. Let's finish this there.
There was a problem hiding this comment.
Let's discuss in mdn/mdn-community#195. If others also feel strongly about this change I can revert it (at best aligning with what we do with other getter-only properties like %TypedArray%.p.length) so we can get the important pieces in.
| @@ -1,8 +1,7 @@ | |||
| --- | |||
| title: RegExp.prototype.dotAll | |||
| title: get RegExp.prototype.dotAll | |||
There was a problem hiding this comment.
I have never seen get used in a title in MDN.
Generally JavaScript has been treated as a little bit special in that it remains closer to spec language that the web api docs. In my strong opinion this might be fine, but it should be raised as a discussion and agreed, not added by magic.
@wbamberg might have an opinion
There was a problem hiding this comment.
Further, if we're going to change the rules, then they should be changed across the docset and reflected in the template guidance for javascript thingies.
It is possible this has been done of course, and I just missed it.
There was a problem hiding this comment.
Further, if we're going to change the rules, then they should be changed across the docset and reflected in the template guidance for javascript thingies.
It is possible this has been done of course, and I just missed it.
See #19540 (comment)
There was a problem hiding this comment.
Yeah, I agree with Hamish that we should do this in an agreed and organized way. Without that I'm -1 on get here.
|
I've hopefully made the content a little clearer and reverted the title changes. I intend to re-propose this sometime in the future when I have more energy. |
d41e04a to
d556ddd
Compare
d556ddd to
383f065
Compare
|
Minor ping for @wbamberg in case you have any feedback on this ^^ The wording change here is pretty important and it's a shame to be delayed so long (the issue has remained for a year and a half) |
f83f23a to
d8c234b
Compare
wbamberg
left a comment
There was a problem hiding this comment.
Mostly copy-edits, though I had a bigger comment on the sticky page. But it's a use-it-or-not-as-you-wish type of thing.
files/en-us/web/javascript/reference/global_objects/regexp/hasindices/index.md
Outdated
Show resolved
Hide resolved
files/en-us/web/javascript/reference/global_objects/regexp/ignorecase/index.md
Outdated
Show resolved
Hide resolved
files/en-us/web/javascript/reference/global_objects/regexp/unicode/index.md
Outdated
Show resolved
Hide resolved
files/en-us/web/javascript/reference/global_objects/regexp/unicode/index.md
Outdated
Show resolved
Hide resolved
files/en-us/web/javascript/reference/global_objects/regexp/unicode/index.md
Outdated
Show resolved
Hide resolved
files/en-us/web/javascript/reference/global_objects/regexp/source/index.md
Outdated
Show resolved
Hide resolved
files/en-us/web/javascript/reference/global_objects/regexp/sticky/index.md
Outdated
Show resolved
Hide resolved
Co-authored-by: wbamberg <will@bootbonnet.ca>
20ab807 to
7090a2c
Compare
7090a2c to
7b0c81c
Compare
7b0c81c to
1d04238
Compare
wbamberg
left a comment
There was a problem hiding this comment.
👍 thank you @Josh-Cena !
* Fix description of regex flags * fix * Fix source * Better wording * Add link * Apply suggestions from code review Co-authored-by: wbamberg <will@bootbonnet.ca> * Add an exhaustive list Co-authored-by: wbamberg <will@bootbonnet.ca>
Summary
Motivation
Fix #1454 (finally!)
Fix #19524 — flags are changed to accessor properties in ES6.
Supporting details
Related issues
Metadata