Array.prototype.replace
Isiah Meadows
isiahmeadows at gmail.com
Thu Jul 12 20:52:42 UTC 2018
I'm the one who suggested syntax over a method. If we go for support
for destructuring, too, I feel this is probably the ideal behavior:
- `[3: c, a, b, ...rest] = foo` should be illegal: positional
properties must come before indexed properties.
- `[a, b, ...rest, 3: c] = foo` should result in `c` being the fourth
result of the iterable (offset 3), but `...rest` also contains it as
its second entry.
But I'm not sure destructuring support is even a good idea to add:
`{3: c} = foo` already works, and I've yet to come across a scenario
where the positional access is even useful apart from off the end
(which is solved by allowing entries after the spread).
-----
Isiah Meadows
me at isiahmeadows.com
www.isiahmeadows.com
On Thu, Jul 12, 2018 at 2:23 PM, Ben Wiley <therealbenwiley at gmail.com> wrote:
> 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