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 < ecmascr...@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 <ljh...@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 <m...@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.pa...@gmail.com> > wrote: > > > > > Le 16 nov. 2015 à 14:01, Alexander Jones <a...@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.pa...@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@mozilla.org > > > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
