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-
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 enco
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 usef
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 th
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
On Tue, Nov 17, 2015 at 4:54 PM, Bergi wrote:
> I could not disagree more with that. Iterators don't have a "left" or
> "right" side, they have a start and an end? The former would be much more
> confusing.
> So when you `padStart` or `trimStart` an iterator you can be sure it will
> always put so
Coroutines schrieb:
I disagree with what has been decided. :p
I was in favor of {trim,pad}{Right,Left}(). The reason: Iterators.
As JS moves forward toward people creating iterators to traverse an
object, referring to the start and end of something *can* be
ambiguous. There is no confusion w
Jeremy Darling schrieb:
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* m
On Tue, Nov 17, 2015 at 2:19 PM, Coroutines wrote:
> In my opinion, if you understand that your script renders
> right-to-left, you would understand that it is encoded/parsed
> left-to-right :>
>
> On Tue, Nov 17, 2015 at 2:13 PM, Claude Pache wrote:
>>
>>> Le 17 nov. 2015 à 22:29, Coroutines a
In my opinion, if you understand that your script renders
right-to-left, you would understand that it is encoded/parsed
left-to-right :>
On Tue, Nov 17, 2015 at 2:13 PM, Claude Pache wrote:
>
>> Le 17 nov. 2015 à 22:29, Coroutines a écrit :
>>
>> There is no confusion with *Left() or *Right().
>
> Le 17 nov. 2015 à 22:29, Coroutines a écrit :
>
> There is no confusion with *Left() or *Right().
In a text string using a right-to-left script (Arabic, Hebrew, etc.),
`trimLeft()` does confusingly "trim at the right".
—Claude
___
es-discuss mail
On Tue, Nov 17, 2015 at 1:13 PM, Jeremy Darling
wrote:
> 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
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, N
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/trimE
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 correc
> Le 16 nov. 2015 à 14:01, Alexander Jones 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 -42). Same
> applies to fi
On Nov 16, 2015, at 0:18 , Jordan Harband wrote:
> 1) The primary use cases in my opinion are monospaced command line output, or
> preformatted text output in a webpage.
These both make assumptions about font rendering: One glyph per Unicode
character, each glyph the same width. ECMAScript is
> Le 16 nov. 2015 à 09:18, Jordan Harband a écrit :
>
>
> 3) The naming is set in stone - `reduceRight` sets a clear precedent that
> "right" is "the length minus one",
True, but `.reduceRight` is for arrays, for which there does not exist a strong
natural notion of "right-to-left" that has
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 -42). Same
applies to filenames for lexicographical sort. Fixed length fields in wire
protoco
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-
Hi Norbert -
Please feel free to file these as issues on the proposal repo (
https://github.com/tc39/proposal-string-pad-left-right). However, I'll try
to answer briefly here:
1) The primary use cases in my opinion are monospaced command line output,
or preformatted text output in a webpage.
2)
The TC39 meeting in September discussed a proposal to add padLeft and padRight
methods to String; the relevant section of the meeting notes [1] is attached
below. A revised proposal is on the agenda for the upcoming November meeting
[2].
Comments on this proposal:
1) The proposal notes that “s
22 matches
Mail list logo
