`String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

`String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

Jacob Pratt
`String.prototype.padStart` and `String.prototype.padEnd` accept the string to pad with as their final parameter. Is there any particular reason `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the same? It would be nice to have a parallel, such that `'foo'.padEnd(10, 'bar').trimEnd('bar') === 'foo'`.

References:

Jacob Pratt

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: `String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

Jordan Harband
`trimStart` and `trimEnd` are better-named versions of the very very long-existing `trimLeft` and `trimRight`, which lack this ability, along with ES5's `trim`.

It wouldn't make sense for these three to differ.

It certainly seems like a potential language proposal to add a string argument to all three; however, at what point is that reimplementing `string.replace(/^(foo)+/, '')`, `string.replace(/(foo)+$/, '')`, and `string.replace(/^(foo)+|$(foo)+$/, '')`? How common is the use case to trim matching substrings off of the ends of a string? (the use cases for padding were quite common)

On Sun, Jun 23, 2019 at 12:14 AM Jacob Pratt <[hidden email]> wrote:
`String.prototype.padStart` and `String.prototype.padEnd` accept the string to pad with as their final parameter. Is there any particular reason `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the same? It would be nice to have a parallel, such that `'foo'.padEnd(10, 'bar').trimEnd('bar') === 'foo'`.

References:

Jacob Pratt
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: `String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

Jacob Pratt
No idea how common of a use case this is; I personally ran across it when reviewing the source code for marked (specifically the [rtrim method]). That example only does characters, not strings, but it's used in the wild by a package with ~2m weekly downloads on npm.

Of course we wouldn't want `trimStart` to differ from `trimLeft`, they'd all be modified in unison. I just think that symmetry between similar methods is important, and (apparently) has use cases.


On Mon, Jun 24, 2019 at 12:46 AM Jordan Harband <[hidden email]> wrote:
`trimStart` and `trimEnd` are better-named versions of the very very long-existing `trimLeft` and `trimRight`, which lack this ability, along with ES5's `trim`.

It wouldn't make sense for these three to differ.

It certainly seems like a potential language proposal to add a string argument to all three; however, at what point is that reimplementing `string.replace(/^(foo)+/, '')`, `string.replace(/(foo)+$/, '')`, and `string.replace(/^(foo)+|$(foo)+$/, '')`? How common is the use case to trim matching substrings off of the ends of a string? (the use cases for padding were quite common)

On Sun, Jun 23, 2019 at 12:14 AM Jacob Pratt <[hidden email]> wrote:
`String.prototype.padStart` and `String.prototype.padEnd` accept the string to pad with as their final parameter. Is there any particular reason `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the same? It would be nice to have a parallel, such that `'foo'.padEnd(10, 'bar').trimEnd('bar') === 'foo'`.

References:

Jacob Pratt
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: `String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

kai zhu
fyi, a search of the entire markedjs/marked repo shows 2 places where rtrim is used:

```js
227 codeBlockStyle: 'indented',
228 text: !this.options.pedantic
229 ? rtrim(cap, '\n')
230 : cap
1425 baseUrls[' ' + base] = rtrim(base, '/', true);
1426 }
1427 }
1428 base = baseUrls[' ' + base];
1429
1430 if (href.slice(0, 2) === '//') {
```

only the 1st use-case does what this thread proposes (the 1st trimRight's "\n", while the 2nd behaves differently and is more like nodejs' `require("path").dirname()`

if i were writing the library, i wouldn't have bothered with a helper-function if its only going to show up in 2 [trivial] places.  would've instead inlined two throwaway regexp-expressions, to keep code more-self-contained / less-fragmented:

```js
228          text: !this.options.pedantic
229            ? cap.replace((/\n+$/), "") // remove trailing "\n" or perhaps just use .trimRight()
230            : cap

1425      baseUrls[' ' + base] = base.replace((/\/[^\/]*$/), "/"); // get "dirname" of base-url
1426    }
```

On Mon, Jun 24, 2019 at 2:27 PM Jacob Pratt <[hidden email]> wrote:
No idea how common of a use case this is; I personally ran across it when reviewing the source code for marked (specifically the [rtrim method]). That example only does characters, not strings, but it's used in the wild by a package with ~2m weekly downloads on npm.

Of course we wouldn't want `trimStart` to differ from `trimLeft`, they'd all be modified in unison. I just think that symmetry between similar methods is important, and (apparently) has use cases.


On Mon, Jun 24, 2019 at 12:46 AM Jordan Harband <[hidden email]> wrote:
`trimStart` and `trimEnd` are better-named versions of the very very long-existing `trimLeft` and `trimRight`, which lack this ability, along with ES5's `trim`.

It wouldn't make sense for these three to differ.

It certainly seems like a potential language proposal to add a string argument to all three; however, at what point is that reimplementing `string.replace(/^(foo)+/, '')`, `string.replace(/(foo)+$/, '')`, and `string.replace(/^(foo)+|$(foo)+$/, '')`? How common is the use case to trim matching substrings off of the ends of a string? (the use cases for padding were quite common)

On Sun, Jun 23, 2019 at 12:14 AM Jacob Pratt <[hidden email]> wrote:
`String.prototype.padStart` and `String.prototype.padEnd` accept the string to pad with as their final parameter. Is there any particular reason `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the same? It would be nice to have a parallel, such that `'foo'.padEnd(10, 'bar').trimEnd('bar') === 'foo'`.

References:

Jacob Pratt
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: `String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

Jacob Pratt
Just thinking about this, the argument that it could be done with regex would also apply to spaces. It's by no means an argument _in favor_, but it clearly wasn't a blocker.

On Mon, Jun 24, 2019 at 4:10 PM kai zhu <[hidden email]> wrote:
fyi, a search of the entire markedjs/marked repo shows 2 places where rtrim is used:

```js
227 codeBlockStyle: 'indented',
228 text: !this.options.pedantic
229 ? rtrim(cap, '\n')
230 : cap
1425 baseUrls[' ' + base] = rtrim(base, '/', true);
1426 }
1427 }
1428 base = baseUrls[' ' + base];
1429
1430 if (href.slice(0, 2) === '//') {
```

only the 1st use-case does what this thread proposes (the 1st trimRight's "\n", while the 2nd behaves differently and is more like nodejs' `require("path").dirname()`

if i were writing the library, i wouldn't have bothered with a helper-function if its only going to show up in 2 [trivial] places.  would've instead inlined two throwaway regexp-expressions, to keep code more-self-contained / less-fragmented:

```js
228          text: !this.options.pedantic
229            ? cap.replace((/\n+$/), "") // remove trailing "\n" or perhaps just use .trimRight()
230            : cap

1425      baseUrls[' ' + base] = base.replace((/\/[^\/]*$/), "/"); // get "dirname" of base-url
1426    }
```

On Mon, Jun 24, 2019 at 2:27 PM Jacob Pratt <[hidden email]> wrote:
No idea how common of a use case this is; I personally ran across it when reviewing the source code for marked (specifically the [rtrim method]). That example only does characters, not strings, but it's used in the wild by a package with ~2m weekly downloads on npm.

Of course we wouldn't want `trimStart` to differ from `trimLeft`, they'd all be modified in unison. I just think that symmetry between similar methods is important, and (apparently) has use cases.


On Mon, Jun 24, 2019 at 12:46 AM Jordan Harband <[hidden email]> wrote:
`trimStart` and `trimEnd` are better-named versions of the very very long-existing `trimLeft` and `trimRight`, which lack this ability, along with ES5's `trim`.

It wouldn't make sense for these three to differ.

It certainly seems like a potential language proposal to add a string argument to all three; however, at what point is that reimplementing `string.replace(/^(foo)+/, '')`, `string.replace(/(foo)+$/, '')`, and `string.replace(/^(foo)+|$(foo)+$/, '')`? How common is the use case to trim matching substrings off of the ends of a string? (the use cases for padding were quite common)

On Sun, Jun 23, 2019 at 12:14 AM Jacob Pratt <[hidden email]> wrote:
`String.prototype.padStart` and `String.prototype.padEnd` accept the string to pad with as their final parameter. Is there any particular reason `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the same? It would be nice to have a parallel, such that `'foo'.padEnd(10, 'bar').trimEnd('bar') === 'foo'`.

References:

Jacob Pratt
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: `String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

Jordan Harband
That's also true, although I believe `\s` in a regex includes line terminators that trim's concept of whitespace does not.

On Mon, Jun 24, 2019 at 4:15 PM Jacob Pratt <[hidden email]> wrote:
Just thinking about this, the argument that it could be done with regex would also apply to spaces. It's by no means an argument _in favor_, but it clearly wasn't a blocker.

On Mon, Jun 24, 2019 at 4:10 PM kai zhu <[hidden email]> wrote:
fyi, a search of the entire markedjs/marked repo shows 2 places where rtrim is used:

```js
227 codeBlockStyle: 'indented',
228 text: !this.options.pedantic
229 ? rtrim(cap, '\n')
230 : cap
1425 baseUrls[' ' + base] = rtrim(base, '/', true);
1426 }
1427 }
1428 base = baseUrls[' ' + base];
1429
1430 if (href.slice(0, 2) === '//') {
```

only the 1st use-case does what this thread proposes (the 1st trimRight's "\n", while the 2nd behaves differently and is more like nodejs' `require("path").dirname()`

if i were writing the library, i wouldn't have bothered with a helper-function if its only going to show up in 2 [trivial] places.  would've instead inlined two throwaway regexp-expressions, to keep code more-self-contained / less-fragmented:

```js
228          text: !this.options.pedantic
229            ? cap.replace((/\n+$/), "") // remove trailing "\n" or perhaps just use .trimRight()
230            : cap

1425      baseUrls[' ' + base] = base.replace((/\/[^\/]*$/), "/"); // get "dirname" of base-url
1426    }
```

On Mon, Jun 24, 2019 at 2:27 PM Jacob Pratt <[hidden email]> wrote:
No idea how common of a use case this is; I personally ran across it when reviewing the source code for marked (specifically the [rtrim method]). That example only does characters, not strings, but it's used in the wild by a package with ~2m weekly downloads on npm.

Of course we wouldn't want `trimStart` to differ from `trimLeft`, they'd all be modified in unison. I just think that symmetry between similar methods is important, and (apparently) has use cases.


On Mon, Jun 24, 2019 at 12:46 AM Jordan Harband <[hidden email]> wrote:
`trimStart` and `trimEnd` are better-named versions of the very very long-existing `trimLeft` and `trimRight`, which lack this ability, along with ES5's `trim`.

It wouldn't make sense for these three to differ.

It certainly seems like a potential language proposal to add a string argument to all three; however, at what point is that reimplementing `string.replace(/^(foo)+/, '')`, `string.replace(/(foo)+$/, '')`, and `string.replace(/^(foo)+|$(foo)+$/, '')`? How common is the use case to trim matching substrings off of the ends of a string? (the use cases for padding were quite common)

On Sun, Jun 23, 2019 at 12:14 AM Jacob Pratt <[hidden email]> wrote:
`String.prototype.padStart` and `String.prototype.padEnd` accept the string to pad with as their final parameter. Is there any particular reason `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the same? It would be nice to have a parallel, such that `'foo'.padEnd(10, 'bar').trimEnd('bar') === 'foo'`.

References:

Jacob Pratt
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss