String.prototype.padLeft / String.prototype.padRight

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

String.prototype.padLeft / String.prototype.padRight

Norbert Lindenberg
The TC39 meeting in September discussed a proposal to add padLeft and padRight methods to String; the relevant section of the meeting notes [1] is attached below. A revised proposal is on the agenda for the upcoming November meeting [2].

Comments on this proposal:

1) The proposal notes that “string padding functions exist in a majority of websites and frameworks”. Unfortunately, it doesn’t provide information on the use cases for which applications need these functions. Without use cases, it’s hard to tell whether the proposed methods are adequate, overengineered, underpowered, or misdirected.

2) The discussion about the unit used for the length arguments can’t be resolved without knowledge of the use cases to be addressed. I can imagine use cases where code units are appropriate, others where code points are appropriate, yet others where tailored grapheme clusters [3] are required, and finally some where padding is required based on the width when rendered with a given font. I don’t know which ones are prevalent in applications in general, and the proposal doesn’t say. If the ones involving font rendering are the most common ones, I’d suggest that the API is not appropriate for ECMAScript because ECMAScript doesn’t deal with fonts.

3) The names of the methods are inappropriate. “Left” and “right” are visual directions, and whether the first or the last characters in a string (or some characters in the middle) are displayed to the left or the right, is decided by the Unicode Bidi Algorithm. Padding, as proposed here, is an operation on logical strings, so “padStart” and “padEnd” should be used. This aligns with the existing startsWith and endsWidth method. Aligning with trimRight/trimLeft is misguided, because these names are equally wrong (they had to be kept because browsers already shipped with these names) [4].

4) Step 10 in the proposed method specifications (“Let truncatedStringFiller be a new String value consisting of repeated concatenations of filler truncated to length fillLen.”) is broken for the case where fillString contains one or more supplementary characters. I can’t imagine a use case where an unpaired surrogate in the result string is the right outcome.

Regards,
Norbert

[1] https://mail.mozilla.org/pipermail/es-discuss/2015-October/044354.html
[2] https://github.com/tc39/proposal-string-pad-left-right
[3] http://www.unicode.org/reports/tr29/
[4] https://mail.mozilla.org/pipermail/es-discuss/2015-July/thread.html#43667


On Oct 6, 2015, at 11:49 , Rick Waldron <[hidden email]> wrote:

> ## 5.10 Proposal: String#padLeft / String#padRight
>
> (Jordan Harband, Rick Waldron)
>
> https://github.com/ljharb/proposal-string-pad-left-right
>
> JHD: (run through history of proposal)
>
> - min length vs. max length semantics? min length semantics with repeat. max length is the desired functionality.
>
> AWB: re: min length and max length, concerning unicode characters, code points.
>
> JHD: Issues will exist in _any_ string apis. This API doesn't use code points, can be changed to do so. Length property wouldn't be useful. If filler is a surrogate pair, I can use a multiple of it's length...
>
> - Max length is in code points?
>
> DH: re: terminal output, do control characters count against length?
>
> JHD: Yes, always.
>
> Discussion, re: code points vs. latin centric characters
>
> BT: This API is no different than existing APIs
>
> JHD: really want to solve this? Change everything to use graphemes
>
> AWB: interpret "length" as simply: "number of occurrences of your fill character"
>
> DD: assumes the rest of your string is Emoji. Never going to get the width correct.
>
> AWB: if it doesn't do the right thing in the real world, why?
>
> BT: Trying to do things beyond the simplest use case is just untenable.
>
> RW: Intl could adopt responsibility for a non-latin character set handling?
>
> BT: Agree.
>
> Derailed into discussion about what gets to go in the standard library and what gets defined in a standard module.
>
> DH: (To Rick) Not cool to attack other specs when inclusion of proposal is questioned.
>
> Note: I made a comment that if two string methods are "too much", then we should revisit SIMD for the same concerns.
>
> Back to padLeft, padRight...
>
> DH: Clearly important if implementers are agreeing to implement before other features.
>
> Discussion re: stage 1 or 2?
>
> AWB: For stage 2, controversy resolved.
>
> JHD: Then stage 1.
>
> #### Conclusion/Resolution
>
> - Stage 1
> - Reviewers to be assigned.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String.prototype.padLeft / String.prototype.padRight

Jordan Harband
Hi Norbert -

Please feel free to file these as issues on the proposal repo (https://github.com/tc39/proposal-string-pad-left-right). However, I'll try to answer briefly here:

1) The primary use cases in my opinion are monospaced command line output, or preformatted text output in a webpage.

2) ECMAScript only has two concepts: code units, and code points - it does not handle grapheme clusters, and if it were to add support for this, these proposed methods could be adapted to handle them in the same way as all of the pre-existing string methods. The issue of code units versus code points has been resolved in https://github.com/tc39/proposal-string-pad-left-right/issues/5 to the satisfaction of the designated spec reviewers and the spec editor.

3) The naming is set in stone - `reduceRight` sets a clear precedent that "right" is "the length minus one", and has no relationship to the visual direction, and based on `trimLeft` and `trimRight`, which are already implemented in basically all browsers Thus, in ECMAScript, "left" is not considered a visual direction but rather a synonym for "start" and "index 0". The naming is also mentioned here: https://github.com/tc39/proposal-string-pad-left-right#naming

4) Per your second question and https://github.com/tc39/proposal-string-pad-left-right/issues/5, this is intentionally not a concern of this proposal.

It'd be much more productive and preferred to continue discussion of this specific proposal on the official repository for that proposal (in this case, https://github.com/tc39/proposal-string-pad-left-right). Thanks!

- Jordan

On Sun, Nov 15, 2015 at 10:39 PM, Norbert Lindenberg <[hidden email]> wrote:
The TC39 meeting in September discussed a proposal to add padLeft and padRight methods to String; the relevant section of the meeting notes [1] is attached below. A revised proposal is on the agenda for the upcoming November meeting [2].

Comments on this proposal:

1) The proposal notes that “string padding functions exist in a majority of websites and frameworks”. Unfortunately, it doesn’t provide information on the use cases for which applications need these functions. Without use cases, it’s hard to tell whether the proposed methods are adequate, overengineered, underpowered, or misdirected.

2) The discussion about the unit used for the length arguments can’t be resolved without knowledge of the use cases to be addressed. I can imagine use cases where code units are appropriate, others where code points are appropriate, yet others where tailored grapheme clusters [3] are required, and finally some where padding is required based on the width when rendered with a given font. I don’t know which ones are prevalent in applications in general, and the proposal doesn’t say. If the ones involving font rendering are the most common ones, I’d suggest that the API is not appropriate for ECMAScript because ECMAScript doesn’t deal with fonts.

3) The names of the methods are inappropriate. “Left” and “right” are visual directions, and whether the first or the last characters in a string (or some characters in the middle) are displayed to the left or the right, is decided by the Unicode Bidi Algorithm. Padding, as proposed here, is an operation on logical strings, so “padStart” and “padEnd” should be used. This aligns with the existing startsWith and endsWidth method. Aligning with trimRight/trimLeft is misguided, because these names are equally wrong (they had to be kept because browsers already shipped with these names) [4].

4) Step 10 in the proposed method specifications (“Let truncatedStringFiller be a new String value consisting of repeated concatenations of filler truncated to length fillLen.”) is broken for the case where fillString contains one or more supplementary characters. I can’t imagine a use case where an unpaired surrogate in the result string is the right outcome.

Regards,
Norbert

[1] https://mail.mozilla.org/pipermail/es-discuss/2015-October/044354.html
[2] https://github.com/tc39/proposal-string-pad-left-right
[3] http://www.unicode.org/reports/tr29/
[4] https://mail.mozilla.org/pipermail/es-discuss/2015-July/thread.html#43667


On Oct 6, 2015, at 11:49 , Rick Waldron <[hidden email]> wrote:

> ## 5.10 Proposal: String#padLeft / String#padRight
>
> (Jordan Harband, Rick Waldron)
>
> https://github.com/ljharb/proposal-string-pad-left-right
>
> JHD: (run through history of proposal)
>
> - min length vs. max length semantics? min length semantics with repeat. max length is the desired functionality.
>
> AWB: re: min length and max length, concerning unicode characters, code points.
>
> JHD: Issues will exist in _any_ string apis. This API doesn't use code points, can be changed to do so. Length property wouldn't be useful. If filler is a surrogate pair, I can use a multiple of it's length...
>
> - Max length is in code points?
>
> DH: re: terminal output, do control characters count against length?
>
> JHD: Yes, always.
>
> Discussion, re: code points vs. latin centric characters
>
> BT: This API is no different than existing APIs
>
> JHD: really want to solve this? Change everything to use graphemes
>
> AWB: interpret "length" as simply: "number of occurrences of your fill character"
>
> DD: assumes the rest of your string is Emoji. Never going to get the width correct.
>
> AWB: if it doesn't do the right thing in the real world, why?
>
> BT: Trying to do things beyond the simplest use case is just untenable.
>
> RW: Intl could adopt responsibility for a non-latin character set handling?
>
> BT: Agree.
>
> Derailed into discussion about what gets to go in the standard library and what gets defined in a standard module.
>
> DH: (To Rick) Not cool to attack other specs when inclusion of proposal is questioned.
>
> Note: I made a comment that if two string methods are "too much", then we should revisit SIMD for the same concerns.
>
> Back to padLeft, padRight...
>
> DH: Clearly important if implementers are agreeing to implement before other features.
>
> Discussion re: stage 1 or 2?
>
> AWB: For stage 2, controversy resolved.
>
> JHD: Then stage 1.
>
> #### Conclusion/Resolution
>
> - Stage 1
> - Reviewers to be assigned.
_______________________________________________
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.padLeft / String.prototype.padRight

Claude Pache
In reply to this post by Norbert Lindenberg
Here are my typical use cases (found by scanning uses of "str_pad" in my PHP codebase):

* transferring data through a protocol that uses fix-length fields;
* formatting things like date/hours, e.g. "08:00" for "8am";
* generating filenames of fixed length, so that they sort correctly, e.g. "foo-00042.txt";
* generating codes of fixed length (e.g. barcodes).

In all those cases, the set of characters is typically limited to ASCII or ISO-8559-1.
Moreover, the filler string consists always of one ASCII character (usually " " or "0").

—Claude

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

Re: String.prototype.padLeft / String.prototype.padRight

Alexander Jones
I see about as little use case for this as `String.prototype.blink`. Date/hours is better solved with zero padding formatting, not just padding out the already stringified number (think negative values -000042). Same applies to filenames for lexicographical sort. Fixed length fields in wire protocols already need to be converted to bytes first before padding, which makes the use of this feature impossible.

On Monday, 16 November 2015, Claude Pache <[hidden email]> wrote:
Here are my typical use cases (found by scanning uses of "str_pad" in my PHP codebase):

* transferring data through a protocol that uses fix-length fields;
* formatting things like date/hours, e.g. "08:00" for "8am";
* generating filenames of fixed length, so that they sort correctly, e.g. "foo-00042.txt";
* generating codes of fixed length (e.g. barcodes).

In all those cases, the set of characters is typically limited to ASCII or ISO-8559-1.
Moreover, the filler string consists always of one ASCII character (usually " " or "0").

—Claude

_______________________________________________
es-discuss mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;es-discuss@mozilla.org&#39;)">es-discuss@...
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.padLeft / String.prototype.padRight

Claude Pache
In reply to this post by Jordan Harband

Le 16 nov. 2015 à 09:18, Jordan Harband <[hidden email]> a écrit :


3) The naming is set in stone - `reduceRight` sets a clear precedent that "right" is "the length minus one",

True, but `.reduceRight` is for arrays, for which there does not exist a strong natural notion of "right-to-left" that has nothing to do with order.

and has no relationship to the visual direction, and based on `trimLeft` and `trimRight`, which are already implemented in basically all browsers Thus, in ECMAScript, "left" is not considered a visual direction but rather a synonym for "start" and "index 0". The naming is also mentioned here: https://github.com/tc39/proposal-string-pad-left-right#naming

When we have two existing competing precedents in the language (left/right vs. starts/ends), why choose to be consistent with the bad one instead of the good one?

A plausible argument for keeping `left/right` would be that other languages have `padLeft`/`padRight`. However, a simple google search shows that better-named `padStart` and `padEnd` are also in use.

—Claude


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

Re: String.prototype.padLeft / String.prototype.padRight

Norbert Lindenberg
In reply to this post by Jordan Harband

On Nov 16, 2015, at 0:18 , Jordan Harband <[hidden email]> wrote:

> 1) The primary use cases in my opinion are monospaced command line output, or preformatted text output in a webpage.

These both make assumptions about font rendering: One glyph per Unicode character, each glyph the same width. ECMAScript is used in a wide range of applications where these assumptions do not hold, and baking them into API causes problems. I think API that primarily is intended for, and limited to, these use cases should be part of libraries for these use cases.

> 2) ECMAScript only has two concepts: code units, and code points - it does not handle grapheme clusters, and if it were to add support for this, these proposed methods could be adapted to handle them in the same way as all of the pre-existing string methods. The issue of code units versus code points has been resolved in https://github.com/tc39/proposal-string-pad-left-right/issues/5 to the satisfaction of the designated spec reviewers and the spec editor.

The conclusion on issue 5 apparently is:

1) Some other programming languages provide functions that are partially broken, so ECMAScript can do the same.

2) Supporting a correct solution “would greatly complicate the algorithm”.

In the two years that I attended TC39 meetings (2011-2013), such arguments were rarely made, and I don’t think they ever ended the discussion. Careful analysis of use cases and in particular of edge cases was the norm.

> 3) The naming is set in stone - `reduceRight` sets a clear precedent that "right" is "the length minus one", and has no relationship to the visual direction, and based on `trimLeft` and `trimRight`, which are already implemented in basically all browsers Thus, in ECMAScript, "left" is not considered a visual direction but rather a synonym for "start" and "index 0". The naming is also mentioned here: https://github.com/tc39/proposal-string-pad-left-right#naming

A stage 1 proposal isn’t set in stone. As Claude pointed out, reduceRight is not a good precedent because arrays have no visual order. The content of strings is commonly associated with a visual order, and that visual order is often not the same as the logical order.

> 4) Per your second question and https://github.com/tc39/proposal-string-pad-left-right/issues/5, this is intentionally not a concern of this proposal.

Per 2) above, it is.

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

Re: String.prototype.padLeft / String.prototype.padRight

Claude Pache
In reply to this post by Alexander Jones

> Le 16 nov. 2015 à 14:01, Alexander Jones <[hidden email]> a écrit :
>
> I see about as little use case for this as `String.prototype.blink`. Date/hours is better solved with zero padding formatting, not just padding out the already stringified number (think negative values -000042). Same applies to filenames for lexicographical sort. Fixed length fields in wire protocols already need to be converted to bytes first before padding, which makes the use of this feature impossible.

Sure, in all those cases I could have used `sprintf` instead of `str_pad`. However, the equivalent of neither one is natively available in JS.

I could write a tagged template that does the equivalent of `sprintf`.... And `.padLeft^H^H^H^HStart` and `.padEnd` would be nice to have for writing more easily such a template,... oh well... :-/

—Claude



>
> On Monday, 16 November 2015, Claude Pache <[hidden email]> wrote:
> Here are my typical use cases (found by scanning uses of "str_pad" in my PHP codebase):
>
> * transferring data through a protocol that uses fix-length fields;
> * formatting things like date/hours, e.g. "08:00" for "8am";
> * generating filenames of fixed length, so that they sort correctly, e.g. "foo-00042.txt";
> * generating codes of fixed length (e.g. barcodes).
>
> In all those cases, the set of characters is typically limited to ASCII or ISO-8559-1.
> Moreover, the filler string consists always of one ASCII character (usually " " or "0").
>
> —Claude
>
> _______________________________________________
> 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.padLeft / String.prototype.padRight

Mohsen Azimi
I might be late to this but please don't use "left" and "right" for referring to start and end of a string. In right to left languages it's confusing. As someone who writes right-to-left we have enough of those "left" and "rights" based on English writing direction. CSS made this mistake but corrected it in later specs. Original box model (margin and padding) used left and right but newer flex box spec uses start and end. Because we made a mistake in the past we don't have to repeat it.

Thanks,
Mohsen Azimi

On Mon, Nov 16, 2015 at 10:44 AM Claude Pache <[hidden email]> wrote:

> Le 16 nov. 2015 à 14:01, Alexander Jones <[hidden email]> a écrit :
>
> I see about as little use case for this as `String.prototype.blink`. Date/hours is better solved with zero padding formatting, not just padding out the already stringified number (think negative values -000042). Same applies to filenames for lexicographical sort. Fixed length fields in wire protocols already need to be converted to bytes first before padding, which makes the use of this feature impossible.

Sure, in all those cases I could have used `sprintf` instead of `str_pad`. However, the equivalent of neither one is natively available in JS.

I could write a tagged template that does the equivalent of `sprintf`.... And `.padLeft^H^H^H^HStart` and `.padEnd` would be nice to have for writing more easily such a template,... oh well... :-/

—Claude



>
> On Monday, 16 November 2015, Claude Pache <[hidden email]> wrote:
> Here are my typical use cases (found by scanning uses of "str_pad" in my PHP codebase):
>
> * transferring data through a protocol that uses fix-length fields;
> * formatting things like date/hours, e.g. "08:00" for "8am";
> * generating filenames of fixed length, so that they sort correctly, e.g. "foo-00042.txt";
> * generating codes of fixed length (e.g. barcodes).
>
> In all those cases, the set of characters is typically limited to ASCII or ISO-8559-1.
> Moreover, the filler string consists always of one ASCII character (usually " " or "0").
>
> —Claude
>
> _______________________________________________
> 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.padLeft / String.prototype.padRight

Jordan Harband
In the TC39 meeting today, we discussed these concerns and decided to rename the proposal from padLeft/padRight to padStart/padEnd (https://github.com/tc39/proposal-string-pad-start-end/commit/35f1ef676f692bfc1099f9ed7c123bd2146f9294) - and correspondingly, to investigate providing trimStart/trimEnd (alongside the legacy trimLeft/trimRight). The consensus remained the same around treatment of code units - which is that, like every other string method, they should conform to the native encoding of strings in the language.

As such, the proposal has now been approved for stage 3 in the TC39 process.

Thanks everyone for providing your input!

- Jordan

On Mon, Nov 16, 2015 at 10:59 AM, Mohsen Azimi <[hidden email]> wrote:
I might be late to this but please don't use "left" and "right" for referring to start and end of a string. In right to left languages it's confusing. As someone who writes right-to-left we have enough of those "left" and "rights" based on English writing direction. CSS made this mistake but corrected it in later specs. Original box model (margin and padding) used left and right but newer flex box spec uses start and end. Because we made a mistake in the past we don't have to repeat it.

Thanks,
Mohsen Azimi

On Mon, Nov 16, 2015 at 10:44 AM Claude Pache <[hidden email]> wrote:

> Le 16 nov. 2015 à 14:01, Alexander Jones <[hidden email]> a écrit :
>
> I see about as little use case for this as `String.prototype.blink`. Date/hours is better solved with zero padding formatting, not just padding out the already stringified number (think negative values -000042). Same applies to filenames for lexicographical sort. Fixed length fields in wire protocols already need to be converted to bytes first before padding, which makes the use of this feature impossible.

Sure, in all those cases I could have used `sprintf` instead of `str_pad`. However, the equivalent of neither one is natively available in JS.

I could write a tagged template that does the equivalent of `sprintf`.... And `.padLeft^H^H^H^HStart` and `.padEnd` would be nice to have for writing more easily such a template,... oh well... :-/

—Claude



>
> On Monday, 16 November 2015, Claude Pache <[hidden email]> wrote:
> Here are my typical use cases (found by scanning uses of "str_pad" in my PHP codebase):
>
> * transferring data through a protocol that uses fix-length fields;
> * formatting things like date/hours, e.g. "08:00" for "8am";
> * generating filenames of fixed length, so that they sort correctly, e.g. "foo-00042.txt";
> * generating codes of fixed length (e.g. barcodes).
>
> In all those cases, the set of characters is typically limited to ASCII or ISO-8559-1.
> Moreover, the filler string consists always of one ASCII character (usually " " or "0").
>
> —Claude
>
> _______________________________________________
> 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



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

Re: String.prototype.padLeft / String.prototype.padRight

Jeremy Darling
Just as an aside, I think padLeft/padRight should still be added in addition to padStart/padEnd.  There are times (token generation, identity padding, etc) where you would want to specify the handedness of the pad operation and ignore the locale.  This goes for the trim* methods as well.

On Tue, Nov 17, 2015 at 3:07 PM, Jordan Harband <[hidden email]> wrote:
In the TC39 meeting today, we discussed these concerns and decided to rename the proposal from padLeft/padRight to padStart/padEnd (https://github.com/tc39/proposal-string-pad-start-end/commit/35f1ef676f692bfc1099f9ed7c123bd2146f9294) - and correspondingly, to investigate providing trimStart/trimEnd (alongside the legacy trimLeft/trimRight). The consensus remained the same around treatment of code units - which is that, like every other string method, they should conform to the native encoding of strings in the language.

As such, the proposal has now been approved for stage 3 in the TC39 process.

Thanks everyone for providing your input!

- Jordan

On Mon, Nov 16, 2015 at 10:59 AM, Mohsen Azimi <[hidden email]> wrote:
I might be late to this but please don't use "left" and "right" for referring to start and end of a string. In right to left languages it's confusing. As someone who writes right-to-left we have enough of those "left" and "rights" based on English writing direction. CSS made this mistake but corrected it in later specs. Original box model (margin and padding) used left and right but newer flex box spec uses start and end. Because we made a mistake in the past we don't have to repeat it.

Thanks,
Mohsen Azimi

On Mon, Nov 16, 2015 at 10:44 AM Claude Pache <[hidden email]> wrote:

> Le 16 nov. 2015 à 14:01, Alexander Jones <[hidden email]> a écrit :
>
> I see about as little use case for this as `String.prototype.blink`. Date/hours is better solved with zero padding formatting, not just padding out the already stringified number (think negative values -000042). Same applies to filenames for lexicographical sort. Fixed length fields in wire protocols already need to be converted to bytes first before padding, which makes the use of this feature impossible.

Sure, in all those cases I could have used `sprintf` instead of `str_pad`. However, the equivalent of neither one is natively available in JS.

I could write a tagged template that does the equivalent of `sprintf`.... And `.padLeft^H^H^H^HStart` and `.padEnd` would be nice to have for writing more easily such a template,... oh well... :-/

—Claude



>
> On Monday, 16 November 2015, Claude Pache <[hidden email]> wrote:
> Here are my typical use cases (found by scanning uses of "str_pad" in my PHP codebase):
>
> * transferring data through a protocol that uses fix-length fields;
> * formatting things like date/hours, e.g. "08:00" for "8am";
> * generating filenames of fixed length, so that they sort correctly, e.g. "foo-00042.txt";
> * generating codes of fixed length (e.g. barcodes).
>
> In all those cases, the set of characters is typically limited to ASCII or ISO-8559-1.
> Moreover, the filler string consists always of one ASCII character (usually " " or "0").
>
> —Claude
>
> _______________________________________________
> 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



_______________________________________________
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.padLeft / String.prototype.padRight

Coroutines
On Tue, Nov 17, 2015 at 1:13 PM, Jeremy Darling
<[hidden email]> wrote:
> Just as an aside, I think padLeft/padRight should still be added in addition
> to padStart/padEnd.  There are times (token generation, identity padding,
> etc) where you would want to specify the handedness of the pad operation and
> ignore the locale.  This goes for the trim* methods as well.

I disagree with what has been decided. :p

I was in favor of {trim,pad}{Right,Left}().  The reason: Iterators.

As JS moves forward toward people creating iterators to traverse an
object, referring to the start and end of something *can* be
ambiguous.  There is no confusion with *Left() or *Right().

I had assumed Start/End were chosen because it would be another move
to avoid very generic names.  Like how we have Array::some() instead
of Array::any(), and Array::every() instead of Array::all().
Less-generic names allows people to monkey-patch without obvious
collisions.  I am a fan of adding to String instead of making my own
XString.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String.prototype.padLeft / String.prototype.padRight

Claude Pache

> Le 17 nov. 2015 à 22:29, Coroutines <[hidden email]> a écrit :
>
> There is no confusion with *Left() or *Right().

In a text string using a right-to-left script (Arabic, Hebrew, etc.), `trimLeft()` does confusingly "trim at the right".

—Claude

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

Re: String.prototype.padLeft / String.prototype.padRight

Coroutines
In my opinion, if you understand that your script renders
right-to-left, you would understand that it is encoded/parsed
left-to-right :>

On Tue, Nov 17, 2015 at 2:13 PM, Claude Pache <[hidden email]> wrote:
>
>> Le 17 nov. 2015 à 22:29, Coroutines <[hidden email]> a écrit :
>>
>> There is no confusion with *Left() or *Right().
>
> In a text string using a right-to-left script (Arabic, Hebrew, etc.), `trimLeft()` does confusingly "trim at the right".
>
> —Claude
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String.prototype.padLeft / String.prototype.padRight

Coroutines
On Tue, Nov 17, 2015 at 2:19 PM, Coroutines <[hidden email]> wrote:

> In my opinion, if you understand that your script renders
> right-to-left, you would understand that it is encoded/parsed
> left-to-right :>
>
> On Tue, Nov 17, 2015 at 2:13 PM, Claude Pache <[hidden email]> wrote:
>>
>>> Le 17 nov. 2015 à 22:29, Coroutines <[hidden email]> a écrit :
>>>
>>> There is no confusion with *Left() or *Right().
>>
>> In a text string using a right-to-left script (Arabic, Hebrew, etc.), `trimLeft()` does confusingly "trim at the right".


Disregard that I top-posted on my reply:

I think I'm just being weird now, you are correct: Silly right-to-left
languages make that just as confusing.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String.prototype.padLeft / String.prototype.padRight

Bergi
In reply to this post by Jeremy Darling
Jeremy Darling schrieb:
> Just as an aside, I think padLeft/padRight should still be added in
> addition to padStart/padEnd.  There are times (token generation, identity
> padding, etc) where you would want to specify the handedness of the pad
> operation and ignore the locale.  This goes for the trim* methods as well.

I don't get that argument. Doesn't `start`/`end` exactly do that: ignore
the locale? It always trims/pads at the start/end of the string,
regardless whether that will be rendered to the left or right of the screen?

  Bergi

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

Re: String.prototype.padLeft / String.prototype.padRight

Bergi
In reply to this post by Coroutines
Coroutines schrieb:

> I disagree with what has been decided. :p
>
> I was in favor of {trim,pad}{Right,Left}().  The reason: Iterators.
>
> As JS moves forward toward people creating iterators to traverse an
> object, referring to the start and end of something *can* be
> ambiguous.  There is no confusion with *Left() or *Right().

I could not disagree more with that. Iterators don't have a "left" or
"right" side, they have a start and an end? The former would be much
more confusing.
So when you `padStart` or `trimStart` an iterator you can be sure it
will always put something in front of it or cut something at the
beginning, regardless whether your iterator does iterate your array or
structure backwards (right-to-left?), from left to right, top-down,
bottom-up, or whatever direction you've drawn/imagined it in.

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

Re: String.prototype.padLeft / String.prototype.padRight

Coroutines
On Tue, Nov 17, 2015 at 4:54 PM, Bergi <[hidden email]> wrote:
> I could not disagree more with that. Iterators don't have a "left" or
> "right" side, they have a start and an end? The former would be much more
> confusing.
> So when you `padStart` or `trimStart` an iterator you can be sure it will
> always put something in front of it or cut something at the beginning,
> regardless whether your iterator does iterate your array or structure
> backwards (right-to-left?), from left to right, top-down, bottom-up, or
> whatever direction you've drawn/imagined it in.

I think you are misunderstanding what I wrote.

"Iterators don't have a "left" or "right" side, they have a start and an end?"

This is my point.  At that time I felt that left and right made more
sense because as we see iterators pick up in use it might be confusing
to see other functions elsewhere that create iterators using start/end
in their names.  I thought that left/right made more sense because
it's very unambiguous that these are not generating functions, and
left/right refers very clearly to the left or right side of the
string.  Someone later replied saying it would still be confusing with
script that is rendered right-to-left, but encoded left-to-right.

There is no win ~ it's been decided anyway, so I'm just laying down my
pitchfork.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String.prototype.padLeft / String.prototype.padRight

Norbert Lindenberg
In reply to this post by Jordan Harband
Thank you for renaming padLeft/padRight to padStart/padEnd.

On the treatment of code units, I was hoping to find more detail in the meeting minutes, but haven’t seen those yet. The native encoding of strings in the language, with the exception of a few parts that we haven’t been able to fix in EcmaScript 2015, is UTF-16, in which some characters take one code unit and others two code units. The current padStart/padEnd proposal doesn’t take that into consideration – it truncates at code unit boundaries rather than code point boundaries, and thus perpetuates problems stemming from obsolete assumptions about Unicode from 1995.

For background on the Unicode problems in pre-2015 EcmaScript see:
https://mathiasbynens.be/notes/javascript-unicode
and the proposed solution that got integrated into EcmaScript 2015:
http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/

Thanks,
Norbert


> On Nov 17, 2015, at 13:07 , Jordan Harband <[hidden email]> wrote:
>
> In the TC39 meeting today, we discussed these concerns and decided to rename the proposal from padLeft/padRight to padStart/padEnd (https://github.com/tc39/proposal-string-pad-start-end/commit/35f1ef676f692bfc1099f9ed7c123bd2146f9294) - and correspondingly, to investigate providing trimStart/trimEnd (alongside the legacy trimLeft/trimRight). The consensus remained the same around treatment of code units - which is that, like every other string method, they should conform to the native encoding of strings in the language.
>
> As such, the proposal has now been approved for stage 3 in the TC39 process.
>
> Thanks everyone for providing your input!
>
> - Jordan
>
> On Mon, Nov 16, 2015 at 10:59 AM, Mohsen Azimi <[hidden email]> wrote:
> I might be late to this but please don't use "left" and "right" for referring to start and end of a string. In right to left languages it's confusing. As someone who writes right-to-left we have enough of those "left" and "rights" based on English writing direction. CSS made this mistake but corrected it in later specs. Original box model (margin and padding) used left and right but newer flex box spec uses start and end. Because we made a mistake in the past we don't have to repeat it.
>
> Thanks,
> Mohsen Azimi
>
> On Mon, Nov 16, 2015 at 10:44 AM Claude Pache <[hidden email]> wrote:
>
> > Le 16 nov. 2015 à 14:01, Alexander Jones <[hidden email]> a écrit :
> >
> > I see about as little use case for this as `String.prototype.blink`. Date/hours is better solved with zero padding formatting, not just padding out the already stringified number (think negative values -000042). Same applies to filenames for lexicographical sort. Fixed length fields in wire protocols already need to be converted to bytes first before padding, which makes the use of this feature impossible.
>
> Sure, in all those cases I could have used `sprintf` instead of `str_pad`. However, the equivalent of neither one is natively available in JS.
>
> I could write a tagged template that does the equivalent of `sprintf`.... And `.padLeft^H^H^H^HStart` and `.padEnd` would be nice to have for writing more easily such a template,... oh well... :-/
>
> —Claude
>
>
>
> >
> > On Monday, 16 November 2015, Claude Pache <[hidden email]> wrote:
> > Here are my typical use cases (found by scanning uses of "str_pad" in my PHP codebase):
> >
> > * transferring data through a protocol that uses fix-length fields;
> > * formatting things like date/hours, e.g. "08:00" for "8am";
> > * generating filenames of fixed length, so that they sort correctly, e.g. "foo-00042.txt";
> > * generating codes of fixed length (e.g. barcodes).
> >
> > In all those cases, the set of characters is typically limited to ASCII or ISO-8559-1.
> > Moreover, the filler string consists always of one ASCII character (usually " " or "0").
> >
> > —Claude
> >
> > _______________________________________________
> > 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
>
>
> _______________________________________________
> 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.padLeft / String.prototype.padRight

Jordan Harband
Closing the loop on this: this proposal is now stage 4 and will be included in ES 2017. https://github.com/tc39/ecma262/pull/581

On Mon, Jan 11, 2016 at 11:40 PM, Norbert Lindenberg <[hidden email]> wrote:
Thank you for renaming padLeft/padRight to padStart/padEnd.

On the treatment of code units, I was hoping to find more detail in the meeting minutes, but haven’t seen those yet. The native encoding of strings in the language, with the exception of a few parts that we haven’t been able to fix in EcmaScript 2015, is UTF-16, in which some characters take one code unit and others two code units. The current padStart/padEnd proposal doesn’t take that into consideration – it truncates at code unit boundaries rather than code point boundaries, and thus perpetuates problems stemming from obsolete assumptions about Unicode from 1995.

For background on the Unicode problems in pre-2015 EcmaScript see:
https://mathiasbynens.be/notes/javascript-unicode
and the proposed solution that got integrated into EcmaScript 2015:
http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/

Thanks,
Norbert


> On Nov 17, 2015, at 13:07 , Jordan Harband <[hidden email]> wrote:
>
> In the TC39 meeting today, we discussed these concerns and decided to rename the proposal from padLeft/padRight to padStart/padEnd (https://github.com/tc39/proposal-string-pad-start-end/commit/35f1ef676f692bfc1099f9ed7c123bd2146f9294) - and correspondingly, to investigate providing trimStart/trimEnd (alongside the legacy trimLeft/trimRight). The consensus remained the same around treatment of code units - which is that, like every other string method, they should conform to the native encoding of strings in the language.
>
> As such, the proposal has now been approved for stage 3 in the TC39 process.
>
> Thanks everyone for providing your input!
>
> - Jordan
>
> On Mon, Nov 16, 2015 at 10:59 AM, Mohsen Azimi <[hidden email]> wrote:
> I might be late to this but please don't use "left" and "right" for referring to start and end of a string. In right to left languages it's confusing. As someone who writes right-to-left we have enough of those "left" and "rights" based on English writing direction. CSS made this mistake but corrected it in later specs. Original box model (margin and padding) used left and right but newer flex box spec uses start and end. Because we made a mistake in the past we don't have to repeat it.
>
> Thanks,
> Mohsen Azimi
>
> On Mon, Nov 16, 2015 at 10:44 AM Claude Pache <[hidden email]> wrote:
>
> > Le 16 nov. 2015 à 14:01, Alexander Jones <[hidden email]> a écrit :
> >
> > I see about as little use case for this as `String.prototype.blink`. Date/hours is better solved with zero padding formatting, not just padding out the already stringified number (think negative values -000042). Same applies to filenames for lexicographical sort. Fixed length fields in wire protocols already need to be converted to bytes first before padding, which makes the use of this feature impossible.
>
> Sure, in all those cases I could have used `sprintf` instead of `str_pad`. However, the equivalent of neither one is natively available in JS.
>
> I could write a tagged template that does the equivalent of `sprintf`.... And `.padLeft^H^H^H^HStart` and `.padEnd` would be nice to have for writing more easily such a template,... oh well... :-/
>
> —Claude
>
>
>
> >
> > On Monday, 16 November 2015, Claude Pache <[hidden email]> wrote:
> > Here are my typical use cases (found by scanning uses of "str_pad" in my PHP codebase):
> >
> > * transferring data through a protocol that uses fix-length fields;
> > * formatting things like date/hours, e.g. "08:00" for "8am";
> > * generating filenames of fixed length, so that they sort correctly, e.g. "foo-00042.txt";
> > * generating codes of fixed length (e.g. barcodes).
> >
> > In all those cases, the set of characters is typically limited to ASCII or ISO-8559-1.
> > Moreover, the filler string consists always of one ASCII character (usually " " or "0").
> >
> > —Claude
> >
> > _______________________________________________
> > 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
>
>
> _______________________________________________
> 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.padLeft / String.prototype.padRight

Norbert Lindenberg
Thanks for the update! It seems though that nothing has been done to fix the problem with supplementary characters. If this issue can’t be addressed for ES 2017, how about at least throwing an exception if fillString is longer than 1 code unit, so that a future edition can do something more useful when the use cases for these methods become clearer?

Thanks,
Norbert


> On May 25, 2016, at 5:56 , Jordan Harband <[hidden email]> wrote:
>
> Closing the loop on this: this proposal is now stage 4 and will be included in ES 2017. https://github.com/tc39/ecma262/pull/581
>
> On Mon, Jan 11, 2016 at 11:40 PM, Norbert Lindenberg <[hidden email]> wrote:
> Thank you for renaming padLeft/padRight to padStart/padEnd.
>
> On the treatment of code units, I was hoping to find more detail in the meeting minutes, but haven’t seen those yet. The native encoding of strings in the language, with the exception of a few parts that we haven’t been able to fix in EcmaScript 2015, is UTF-16, in which some characters take one code unit and others two code units. The current padStart/padEnd proposal doesn’t take that into consideration – it truncates at code unit boundaries rather than code point boundaries, and thus perpetuates problems stemming from obsolete assumptions about Unicode from 1995.
>
> For background on the Unicode problems in pre-2015 EcmaScript see:
> https://mathiasbynens.be/notes/javascript-unicode
> and the proposed solution that got integrated into EcmaScript 2015:
> http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/
>
> Thanks,
> Norbert
>
>
> > On Nov 17, 2015, at 13:07 , Jordan Harband <[hidden email]> wrote:
> >
> > In the TC39 meeting today, we discussed these concerns and decided to rename the proposal from padLeft/padRight to padStart/padEnd (https://github.com/tc39/proposal-string-pad-start-end/commit/35f1ef676f692bfc1099f9ed7c123bd2146f9294) - and correspondingly, to investigate providing trimStart/trimEnd (alongside the legacy trimLeft/trimRight). The consensus remained the same around treatment of code units - which is that, like every other string method, they should conform to the native encoding of strings in the language.
> >
> > As such, the proposal has now been approved for stage 3 in the TC39 process.
> >
> > Thanks everyone for providing your input!
> >
> > - Jordan
> >
> > On Mon, Nov 16, 2015 at 10:59 AM, Mohsen Azimi <[hidden email]> wrote:
> > I might be late to this but please don't use "left" and "right" for referring to start and end of a string. In right to left languages it's confusing. As someone who writes right-to-left we have enough of those "left" and "rights" based on English writing direction. CSS made this mistake but corrected it in later specs. Original box model (margin and padding) used left and right but newer flex box spec uses start and end. Because we made a mistake in the past we don't have to repeat it.
> >
> > Thanks,
> > Mohsen Azimi
> >
> > On Mon, Nov 16, 2015 at 10:44 AM Claude Pache <[hidden email]> wrote:
> >
> > > Le 16 nov. 2015 à 14:01, Alexander Jones <[hidden email]> a écrit :
> > >
> > > I see about as little use case for this as `String.prototype.blink`. Date/hours is better solved with zero padding formatting, not just padding out the already stringified number (think negative values -000042). Same applies to filenames for lexicographical sort. Fixed length fields in wire protocols already need to be converted to bytes first before padding, which makes the use of this feature impossible.
> >
> > Sure, in all those cases I could have used `sprintf` instead of `str_pad`. However, the equivalent of neither one is natively available in JS.
> >
> > I could write a tagged template that does the equivalent of `sprintf`.... And `.padLeft^H^H^H^HStart` and `.padEnd` would be nice to have for writing more easily such a template,... oh well... :-/
> >
> > —Claude
> >
> >
> >
> > >
> > > On Monday, 16 November 2015, Claude Pache <[hidden email]> wrote:
> > > Here are my typical use cases (found by scanning uses of "str_pad" in my PHP codebase):
> > >
> > > * transferring data through a protocol that uses fix-length fields;
> > > * formatting things like date/hours, e.g. "08:00" for "8am";
> > > * generating filenames of fixed length, so that they sort correctly, e.g. "foo-00042.txt";
> > > * generating codes of fixed length (e.g. barcodes).
> > >
> > > In all those cases, the set of characters is typically limited to ASCII or ISO-8559-1.
> > > Moreover, the filler string consists always of one ASCII character (usually " " or "0").
> > >
> > > —Claude
> > >
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12