Re: Extended dot notation (pick notation) proposal

On Wed, Sep 7, 2016, 04:10 Kris Siegel wrote: > > I'm just saying those references still exist, and ignoring them will > lead you into more problems than this would solve. > > Not suggesting anything of the sort only that your workaround adds > additional variables with

Re: Extended dot notation (pick notation) proposal

> I'm just saying those references still exist, and ignoring them will lead you into more problems than this would solve. Not suggesting anything of the sort only that your workaround adds additional variables with possible object references and a more native implementation could work around

Re: Endorse an unambiguous syntax for ES2015 modules

I suggest re-reading Domenic's two replies; they quite exhaust the topic, I think. On 12:31AM, Wed, Sep 7, 2016 martin heidegger wrote: > > This is not correct. There is nothing backward-incompatible about > adding a new top-level grammar goal. And the new grammar

Re: Function composition syntax

Hi, interesting proposal! Here's what I propose: a new infix operator `>=>` (operator and direction can change) for composing two functions. Sweet, reminds me of Kleisli composition in Haskell http://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Monad.html#v:-62--61--62- (which does

Function composition syntax

I would like to see a function composition operator make it into the language. Currently, there is: - Lodash: `_.flow` and `_.flowRight` (lodash/fp alias: `_.compose` and `_.composeRight`) - Underscore: `_.compose` - Ramda: `R.compose` - Tons of npm modules:

Re: Function composition syntax

> Create a callable-only function that calls its left operand with the original > arguments and `this`, then calling its right operand with the result and the > same `this`. IMHO, the order seems wrong. Not sure if programming languages do it differently, but in math composition works like

Re: Function composition syntax

Inline. On Wed, Sep 7, 2016, 10:44 Bergi wrote: > Hi, > interesting proposal! > > > Here's what I propose: a new infix operator `>=>` (operator and direction > > can change) for composing two functions. > > Sweet, reminds me of Kleisli composition in Haskell > >

Re: Function composition syntax

Inline. On Wed, Sep 7, 2016, 11:05 Mike Samuel wrote: > On Wed, Sep 7, 2016 at 10:10 AM, Isiah Meadows > wrote: > > I would like to see a function composition operator make it into the > > language. Currently, there is: > > > > - Lodash: `_.flow`

Re: Reflect.hasOwn

> > On Sep 6, 2016, at 4:10 PM, Domenic Denicola wrote: > > Reflect is a namespace that contains the proxy traps (it’s a bit of an > unfortunate name), so we shouldn’t be adding things to it that are not part > of the meta-object protocol. I generally disagree with the idea

Re: Reflect.hasOwn

Removing hasOwnProperty from Object.prototype would break a lot of code, so it's not even an option, but we could at least add Object.hasOwn, since Reflect apparently isn't the right place for this (it's a shame, it would mirror nicely with Reflect.ownKeys). Doing this would improve a bit the

Re: Reflect.hasOwn

Just my 2 cents. The tiniest JS utility I know [1] solves verbosity and freeze the method so it's also safe. ```js // meet callerOf function callerOf(c) {return c.call.bind(c)} // how to use it const hasOwn = callerOf({}.hasOwnProperty); hasOwn({key: 'value'}, 'key'); // true hasOwn({value:

Re: Re: ES8 Proposal: Optional Static Typing

I'm just an observer who occasionally contributes to this list, but I don't see static types making it into ES any time soon. First, no type checker (TypeScript, Flow, or any other) can fully check the core language (most notably `bind`, `apply`, `call`, and `Object.assign`). Second, they both

Fwd: Function composition syntax

Somehow, this missed the list... -- Forwarded message - From: Isiah Meadows Date: Wed, Sep 7, 2016, 12:03 Subject: Re: Function composition syntax To: , I was thinking in reverse order, but personally, I'm