String.prototype.padLeft / String.prototype.padRight

Cyril Auburtin cyril.auburtin at gmail.com
Wed Jun 1 07:28:00 UTC 2016


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 <ljharb at gmail.com>:

> 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 <
> ecmascript at lindenbergsoftware.com> 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 <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
>> > > >
>>
>
>
> _______________________________________________
> 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/20160601/9506318a/attachment.html>


More information about the es-discuss mailing list