String.prototype.padLeft / String.prototype.padRight

Jeremy Darling jeremy.darling at gmail.com
Tue Nov 17 21:13:07 UTC 2015


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 <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/20151117/ce2eacda/attachment-0001.html>


More information about the es-discuss mailing list