Array.prototype.replace
Ben Wiley
therealbenwiley at gmail.com
Thu Jul 12 18:23:43 UTC 2018
I think this discussion has devolved far beyond the latest in the on-topic thread which concerned a syntax proposal for array spreading with replacement.
Did anyone have thoughts on that?
To recap, the array rest spread assignment proposal:
const arr1 = [1,2,3]
const arr2 = [...arr1, 1: 4] // [1,4,3]
Additional proposal for destructuring:
const [...arr3, 1: b] = arr2
console.log(arr3) // [1,3]
console.log(b) // 4
Potential problems with the destructuring proposal:
const arr4 = [1,2,3,4,5]
const [a, ...arr5, 2: b] = arr4
console.log(a, arr5, b) // is this... 1, [2,4,5], 3 ? or... 1, [2,3,5], 4 ?
const [c, ...arr6, 0: d] = arr4
console.log(c, arr6, d) // is this... 1, [2,3,4,5], 1 ? or... 1, [3,4,5], 2 ?
The destructuring bit seems kind of cool but potentially very hard to read, even if those ambiguities are resolved.
I'd be fine pushing ahead with only the first proposal (const arr2 = [...arr1, 1: 4]).
Ben
On 2018-07-12, 2:00 PM, "kai zhu" <kaizhu256 at gmail.com> wrote:
> The iterable utilities would be geared towards *sync* iterators primarily,
> which are typically *not* used for I/O.
can you give common use-cases for javascript *sync* iterators in an
industry-context (e.g. web-programming) that are superior to existing
es5 design-patterns? because i honestly cannot think of any. as a
former pythonista (for 7 years), i recall using python-iterators
primarily for blocking-io (e.g. readline) or algorithms, both of which
are niche-applications of javascript in industry (nobody hires
javascript-programmers to waste *days* writing algorithms, when
good-enough results can be achieved in *hours* with sqlite3 or
child_process calls to imagemagick/numpy/grep/find/"rm -r"/etc).
the typical scenario for *sync* iterators that plays out in my head,
is that the pm will eventually request a feature requiring unavoidable
async io, turning the *sync* iterator into an *async* one, which
quickly devolves into technical-debt during integration (and will
eventually have to be rewritten as a non-iterator for anyone who has
the will to do the cleanup).
On 7/12/18, Isiah Meadows <isiahmeadows at gmail.com> wrote:
> The iterable utilities would be geared towards *sync* iterators primarily,
> which are typically *not* used for I/O. They would have more in common with
> Lodash than RxJS.
>
> And JS is not async-first - that's Go, Haskell (with GHC), Clojure
> (somewhat), and some mostly obscure and/or niche languages, which feature
> non-blocking I/O with deep language integration (you don't have to code
> explicit support for it) complete with easy parallelism and syntactic sugar
> for other things concurrency-related. JS is async-second, like C# and F#,
> which each feature native non-blocking and (in some cases) optional
> blocking I/O along with native syntax and/or DSLs with appropriate builtins
> to support the non-blocking variants, but you still have to code specially
> for them.
>
> Observables are typically used for *input*, not *output*, but they do
> actually shine well for what they do. They aren't IMHO the ideal
> abstraction, but they're pretty close for relatively procedural languages.
> (I prefer duplex streams as a primitive, not observables - they're usually
> more fault-tolerant, and they're easier to compose and integrate with.)
>
> One last thing: Koa now uses promises, not generators. They only used
> generators to emulate what async functions provided, and they first made
> the decision before the feature went stable in V8, even before the feature
> hit stage 4 in the spec.
>
> On Wed, Jul 11, 2018, 12:06 kai zhu <kaizhu256 at gmail.com> wrote:
>
>> > 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
>> >>
>> >>
>> >
>>
>
More information about the es-discuss
mailing list