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" <kaizhu...@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 <isiahmead...@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 <kaizhu...@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 <isiahmead...@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
    >> > m...@isiahmeadows.com
    >> > www.isiahmeadows.com
    >> >
    >> > On Tue, Jul 10, 2018 at 11:18 AM, Ben Wiley <therealbenwi...@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.giammar...@gmail.com>
    >> >> *Date: *Tuesday, July 10, 2018 at 10:50 AM
    >> >> *To: *"T.J. Crowder" <tj.crow...@farsightsoftware.com>
    >> >> *Cc: *"therealbenwi...@gmail.com" <therealbenwi...@gmail.com>, "
    >> >> es-discuss@mozilla.org" <es-discuss@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.crow...@farsightsoftware.com> wrote:
    >> >>
    >> >> On Tue, Jul 10, 2018 at 2:18 PM, Ben Wiley <therealbenwi...@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@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

Reply via email to