String.prototype.padLeft / String.prototype.padRight

[Jordan Harband]

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) ECMAScript only has two concepts: code units, and code points - it does
not handle grapheme clusters, and if it were to add support for this, these
proposed methods could be adapted to handle them in the same way as all of
the pre-existing string methods. The issue of code units versus code points
has been resolved in
https://github.com/tc39/proposal-string-pad-left-right/issues/5 to the
satisfaction of the designated spec reviewers and the spec editor.

3) The naming is set in stone - `reduceRight` sets a clear precedent that
"right" is "the length minus one", and has no relationship to the visual
direction, and based on `trimLeft` and `trimRight`, which are already
implemented in basically all browsers Thus, in ECMAScript, "left" is not
considered a visual direction but rather a synonym for "start" and "index
0". The naming is also mentioned here:
https://github.com/tc39/proposal-string-pad-left-right#naming

4) Per your second question and
https://github.com/tc39/proposal-string-pad-left-right/issues/5, this is
intentionally not a concern of this proposal.

It'd be much more productive and preferred to continue discussion of this
specific proposal on the official repository for that proposal (in this
case, https://github.com/tc39/proposal-string-pad-left-right). Thanks!

- Jordan

On Sun, Nov 15, 2015 at 10:39 PM, Norbert Lindenberg <
ecmascript at lindenbergsoftware.com> wrote:

> 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 “string padding functions exist in a majority
> of websites and frameworks”. Unfortunately, it doesn’t provide information
> on the use cases for which applications need these functions. Without use
> cases, it’s hard to tell whether the proposed methods are adequate,
> overengineered, underpowered, or misdirected.
>
> 2) The discussion about the unit used for the length arguments can’t be
> resolved without knowledge of the use cases to be addressed. I can imagine
> use cases where code units are appropriate, others where code points are
> appropriate, yet others where tailored grapheme clusters [3] are required,
> and finally some where padding is required based on the width when rendered
> with a given font. I don’t know which ones are prevalent in applications in
> general, and the proposal doesn’t say. If the ones involving font rendering
> are the most common ones, I’d suggest that the API is not appropriate for
> ECMAScript because ECMAScript doesn’t deal with fonts.
>
> 3) The names of the methods are inappropriate. “Left” and “right” are
> visual directions, and whether the first or the last characters in a string
> (or some characters in the middle) are displayed to the left or the right,
> is decided by the Unicode Bidi Algorithm. Padding, as proposed here, is an
> operation on logical strings, so “padStart” and “padEnd” should be used.
> This aligns with the existing startsWith and endsWidth method. Aligning
> with trimRight/trimLeft is misguided, because these names are equally wrong
> (they had to be kept because browsers already shipped with these names) [4].
>
> 4) Step 10 in the proposed method specifications (“Let
> truncatedStringFiller be a new String value consisting of repeated
> concatenations of filler truncated to length fillLen.”) is broken for the
> case where fillString contains one or more supplementary characters. I
> can’t imagine a use case where an unpaired surrogate in the result string
> is the right outcome.
>
> Regards,
> Norbert
>
> [1] https://mail.mozilla.org/pipermail/es-discuss/2015-October/044354.html
> [2] https://github.com/tc39/proposal-string-pad-left-right
> [3] http://www.unicode.org/reports/tr29/
> [4]
> https://mail.mozilla.org/pipermail/es-discuss/2015-July/thread.html#43667
>
>
> On Oct 6, 2015, at 11:49 , Rick Waldron <waldron.rick at gmail.com> wrote:
>
> > ## 5.10 Proposal: String#padLeft / String#padRight
> >
> > (Jordan Harband, Rick Waldron)
> >
> > https://github.com/ljharb/proposal-string-pad-left-right
> >
> > JHD: (run through history of proposal)
> >
> > - min length vs. max length semantics? min length semantics with repeat.
> max length is the desired functionality.
> >
> > AWB: re: min length and max length, concerning unicode characters, code
> points.
> >
> > JHD: Issues will exist in _any_ string apis. This API doesn't use code
> points, can be changed to do so. Length property wouldn't be useful. If
> filler is a surrogate pair, I can use a multiple of it's length...
> >
> > - Max length is in code points?
> >
> > DH: re: terminal output, do control characters count against length?
> >
> > JHD: Yes, always.
> >
> > Discussion, re: code points vs. latin centric characters
> >
> > BT: This API is no different than existing APIs
> >
> > JHD: really want to solve this? Change everything to use graphemes
> >
> > AWB: interpret "length" as simply: "number of occurrences of your fill
> character"
> >
> > DD: assumes the rest of your string is Emoji. Never going to get the
> width correct.
> >
> > AWB: if it doesn't do the right thing in the real world, why?
> >
> > BT: Trying to do things beyond the simplest use case is just untenable.
> >
> > RW: Intl could adopt responsibility for a non-latin character set
> handling?
> >
> > BT: Agree.
> >
> > Derailed into discussion about what gets to go in the standard library
> and what gets defined in a standard module.
> >
> > DH: (To Rick) Not cool to attack other specs when inclusion of proposal
> is questioned.
> >
> > Note: I made a comment that if two string methods are "too much", then
> we should revisit SIMD for the same concerns.
> >
> > Back to padLeft, padRight...
> >
> > DH: Clearly important if implementers are agreeing to implement before
> other features.
> >
> > Discussion re: stage 1 or 2?
> >
> > AWB: For stage 2, controversy resolved.
> >
> > JHD: Then stage 1.
> >
> > #### Conclusion/Resolution
> >
> > - Stage 1
> > - Reviewers to be assigned.
> _______________________________________________
> 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/20151116/30bad6bc/attachment-0001.html>