Array.prototype.replace

[kai zhu]

> The main things I know of that are blocked on the pipeline operator IIUC
> are observables and iterable utilities.

unlike synchronous languages like python where everything blocks, do
we really want iterable utilities for a [one-of-a-kind] async-first
language like javascript?

nothing good has ever come from mixing generators with async i/o from
my experience.  it typically results in hard-to-reason
logical-nightmares (and hard-to-fix timeout bugs), that makes
web-project integration-work more hellish than it already is (think of
how un-debuggable most projects that use koajs-middlewares end up).

-kai

On 7/11/18, Isiah Meadows <isiahmeadows at gmail.com> wrote:
> The main things I know of that are blocked on the pipeline operator IIUC
> are observables and iterable utilities. As-is, using observables without
> methods or a pipeline operator starts to feel like you're using Lisp, not
> JS, because of the sheer number of operators. (It's an array over *time*,
> not *space*, so you have things like debouncing, throttling, etc. that you
> have to address.) Iterables are in a similar situation because they're
> lazy, it's protocol-based rather than prototype-based, and JS lacks
> anything like monads.
>
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
> www.isiahmeadows.com
>
> On Tue, Jul 10, 2018 at 11:18 AM, Ben Wiley <therealbenwiley at gmail.com>
> wrote:
>
>> It’s not clear to me that pursuit of new Array methods should be
>> abandoned
>> purely on speculation that the pipe operator will pass Stage 1.
>>
>>
>>
>> That said, the realization that Object.assign provides this functionality
>> is enough for me to quit pursuing (my version of)
>> Array.prototype.replace.
>>
>>
>>
>> I’d prefer that further discussion concern the earlier-discussed
>> extension
>> to the Array rest spread syntax. :)
>>
>>
>>
>> Ben
>>
>>
>>
>> *From: *Andrea Giammarchi <andrea.giammarchi at gmail.com>
>> *Date: *Tuesday, July 10, 2018 at 10:50 AM
>> *To: *"T.J. Crowder" <tj.crowder at farsightsoftware.com>
>> *Cc: *"therealbenwiley at gmail.com" <therealbenwiley at gmail.com>, "
>> es-discuss at mozilla.org" <es-discuss at mozilla.org>
>> *Subject: *Re: Array.prototype.replace
>>
>>
>>
>> just a few days ago another full stack JS dev mentioned Array replace and
>> it has nothing to do with what was proposed in here:
>>
>> https://medium.com/@gajus/the-case-for-array-replace-cd9330707243
>>
>>
>>
>> My TL;DR response was that once the pipe operator is in, everyone can
>> bring in its own meaning for `array |> replace` and call it a day.
>>
>>
>>
>> Keep polluting the already most polluted prototype of them all doesn't
>> look like a good strategy to improve the language.
>>
>>
>>
>> Just my 2 cents.
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jul 10, 2018 at 3:37 PM T.J. Crowder <
>> tj.crowder at farsightsoftware.com> wrote:
>>
>> On Tue, Jul 10, 2018 at 2:18 PM, Ben Wiley <therealbenwiley at gmail.com>
>> wrote:
>> > Hm, despite the fewer number of points in the cons category I'm
>> persuaded by
>> > the argument that we don't want people getting arrays and objects
>> confused.
>> > Might be best to limit that until there is a compelling use case which
>> there
>> > might not be.
>>
>> Heh, whereas despite having written that first bullet in the footgun
>> column somewhat forcefully (looking back), I go the other way. :-)
>>
>>
>>
>> -- T.J. Crowder
>>
>> _______________________________________________
>> 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
>>
>>
>