String.prototype.padLeft / String.prototype.padRight

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

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

Jordan Harband
The time for that kind of change has long past - and the current use cases for multi-char fill strings work with the current methods. I'll repeat - "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." - in other words, there's no "problem" with supplementary characters that needs fixing, at least at the granularity level of "specific API methods".

On Tue, May 31, 2016 at 10:26 PM, Norbert Lindenberg <[hidden email]> wrote:
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
Reply | Threaded
Open this post in threaded view
|

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

Cyril Auburtin
Like Alexander, I see no general use case for this, and no point in adding it. It's more or less simply `('0'.repeat(n)+value).slice(-n)`.

If it was to really add it, there could also be other ways like adding it to Date API (where it's mostly used) or as a more general String.format method

2016-06-01 8:29 GMT+02:00 Jordan Harband <[hidden email]>:
The time for that kind of change has long past - and the current use cases for multi-char fill strings work with the current methods. I'll repeat - "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." - in other words, there's no "problem" with supplementary characters that needs fixing, at least at the granularity level of "specific API methods".

On Tue, May 31, 2016 at 10:26 PM, Norbert Lindenberg <[hidden email]> wrote:
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



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