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 <[email protected]>: > 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 < > [email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 <[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
