String.prototype.padLeft / String.prototype.padRight

Jordan Harband ljharb at gmail.com
Wed May 25 12:56:04 UTC 2016


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
> > >
> > > _______________________________________________
> > > es-discuss mailing list
> > > es-discuss at mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160525/3c13110f/attachment.html>


More information about the es-discuss mailing list