String.prototype.trimRight/trimLeft

[Behrang Saeedzadeh]

I think poly-filling is only a good idea when the spec says a given type
should have a given function but one or more browsers haven't implemented
it yet.

Otherwise it will become like the era of overtly monkey patching everything
in Ruby that could end up with libraries clashing with each other and
leading to lots of headaches for developers.

Unless something similar to C#'s extension methods are added to EcmaScript:
https://msdn.microsoft.com/en-AU/library/bb383977.aspx that can turned on a
polyfill on a per scope basis.



On Thu, Jul 30, 2015 at 1:12 AM Michał Wadas <michalwadas at gmail.com> wrote:

> I can't remember last time when I would need `isNullOrEmpty` -
> Boolean('') and Boolean(null) evaluates to false. And `if (str)`
> handles any case with consistent types.
>
> String.isNullOrEmpty = (a)=>(typeof a === 'string' || a === null) && !a;
>
> Anyway - native isNullOrWhiteSpace would be probably be useful only to
> reduce GC pressure, because it's easily polyfilled.
>
> String.isNullOrWhiteSpace = (a)=>a === null ? true : typeof a ===
> 'string' && !a.trim();
>
>
> 2015-07-29 13:27 GMT+02:00 Behrang Saeedzadeh <behrangsa at gmail.com>:
> > Another set of very handy functions that in Java are provided by
> libraries
> > such as Guava or Apache Commons and in C# are built in, are
> > `String.isNullOrEmpty(aStr)` and `String.IsNullOrWhiteSpace(aStr)`.
> >
> > Would be nice if they ES Strings had them too.
> >
> > On Tue, Jul 28, 2015 at 10:15 AM John-David Dalton
> > <john.david.dalton at gmail.com> wrote:
> >>
> >> In the wild I've seen ltrim rtrim which are variations of trimLeft and
> >> trimRight and padLeft padRight or lpad, rpad for other forms. For
> stings I
> >> think of left and right as leading and trailing and think of start and
> end
> >> as more position indicators of like slice or a range.
> >>
> >>
> >> -JDD
> >>
> >> On Mon, Jul 27, 2015 at 4:55 PM, Dmitry Soshnikov
> >> <dmitry.soshnikov at gmail.com> wrote:
> >>>
> >>> OK, it was added to the agenda for the next meeting (will be presented
> by
> >>> Sebastian Markbage), so can be discussed in detail. I agree that
> "start",
> >>> and "end" are now probably better fit (because of i18n, and a strong
> >>> correlation with "startsWith" and "endsWith"). We can probably ignore
> the
> >>> de-facto shipped in browsers, they will just implement in addition
> >>> `trimStart` and `trimEnd`, and eventually deprecate the "right" and
> "left".
> >>>
> >>> Dmitry
> >>>
> >>> On Tue, Jul 21, 2015 at 12:02 AM, Claude Pache <claude.pache at gmail.com
> >
> >>> wrote:
> >>>>
> >>>>
> >>>> > Le 21 juil. 2015 à 08:28, Jordan Harband <ljharb at gmail.com> a
> écrit :
> >>>> >
> >>>> > On the contrary -"left" always begins at index 0 - "start" is
> >>>> > sometimes index 0, sometimes index (length - 1).
> >>>>
> >>>> Counter-example: ES6 methods `String#startsWith` and `String#endsWith`
> >>>> are named correctly.
> >>>>
> >>>> > I think "left" and "right" are the right names; "start" and "end"
> >>>> > would require unicode bidirectional stuff.
> >>>>
> >>>> No, because characters in Unicode strings are ordered logically, not
> >>>> visually.
> >>>>
> >>>> —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
> >
> > --
> > Best regards,
> > Behrang Saeedzadeh
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
-- 
Best regards,
Behrang Saeedzadeh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150730/f45aa868/attachment-0001.html>