Value types status

[Isiah Meadows]

I haven't been able to find much talk on the value types proposal lately.
What's the status of it?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.padLeft / String.prototype.padRight

[Jordan Harband]

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  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 
> wrote:
>
>>
>> > 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 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 
>> 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@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.padLeft / String.prototype.padRight

[Bergi]

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 with *Left() or *Right().


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 something in front of it or cut something at the 
beginning, regardless whether your iterator does iterate your array or 
structure backwards (right-to-left?), from left to right, top-down, 
bottom-up, or whatever direction you've drawn/imagined it in.


 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.padLeft / String.prototype.padRight

[Bergi]

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* methods as well.


I don't get that argument. Doesn't `start`/`end` exactly do that: ignore 
the locale? It always trims/pads at the start/end of the string, 
regardless whether that will be rendered to the left or right of the screen?


 Bergi

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.padLeft / String.prototype.padRight

[Coroutines]

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 something in front of it or cut something at the beginning,
> regardless whether your iterator does iterate your array or structure
> backwards (right-to-left?), from left to right, top-down, bottom-up, or
> whatever direction you've drawn/imagined it in.

I think you are misunderstanding what I wrote.

"Iterators don't have a "left" or "right" side, they have a start and an end?"

This is my point.  At that time I felt that left and right made more
sense because as we see iterators pick up in use it might be confusing
to see other functions elsewhere that create iterators using start/end
in their names.  I thought that left/right made more sense because
it's very unambiguous that these are not generating functions, and
left/right refers very clearly to the left or right side of the
string.  Someone later replied saying it would still be confusing with
script that is rendered right-to-left, but encoded left-to-right.

There is no win ~ it's been decided anyway, so I'm just laying down my
pitchfork.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.padLeft / String.prototype.padRight

[Coroutines]

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 the locale.  This goes for the trim* methods as well.

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 with *Left() or *Right().

I had assumed Start/End were chosen because it would be another move
to avoid very generic names.  Like how we have Array::some() instead
of Array::any(), and Array::every() instead of Array::all().
Less-generic names allows people to monkey-patch without obvious
collisions.  I am a fan of adding to String instead of making my own
XString.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.padLeft / String.prototype.padRight

[Coroutines]

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().
>
> In a text string using a right-to-left script (Arabic, Hebrew, etc.), 
> `trimLeft()` does confusingly "trim at the right".
>
> —Claude
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.padLeft / String.prototype.padRight

[Jeremy Darling]

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  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  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 
>> wrote:
>>
>>>
>>> > 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 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 
>>> 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@mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.padLeft / String.prototype.padRight

[Claude Pache]

> 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 mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss