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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> wrote: >> >>> >>> > Le 16 nov. 2015 à 14:01, Alexander Jones <[email protected]> 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 <[email protected]> >>> 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 >>> > [email protected] >>> > https://mail.mozilla.org/listinfo/es-discuss >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
