String.prototype.padLeft / String.prototype.padRight

Norbert Lindenberg ecmascript at lindenbergsoftware.com
Wed Jun 1 05:26:17 UTC 2016


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 <ljharb at gmail.com> 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 <ecmascript at lindenbergsoftware.com> 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 <ljharb at gmail.com> 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 <me at azimi.me> 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 <claude.pache at gmail.com> wrote:
> >
> > > Le 16 nov. 2015 à 14:01, Alexander Jones <alex at weej.com> 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 <claude.pache at gmail.com> 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
> > >


More information about the es-discuss mailing list