Re: Calling toString on function proxy throws TypeError exception

> Le 26 oct. 2015 à 20:20, Allen Wirfs-Brock a écrit : > > >> On Oct 26, 2015, at 11:20 AM, Mark Miller wrote: >> >> I like the idea a function proxy is more encapsulating of its implementation >> than a function is. >> >> I also like the idea of

Re: Calling toString on function proxy throws TypeError exception

> Le 27 oct. 2015 à 09:35, Claude Pache a écrit : > > >> Le 26 oct. 2015 à 20:20, Allen Wirfs-Brock a écrit : >> >> >>> On Oct 26, 2015, at 11:20 AM, Mark Miller wrote: >>> >>> I like the idea a function proxy is more

Re: Calling toString on function proxy throws TypeError exception

On 10/27/15 4:35 AM, Claude Pache wrote: it is that, for any callable object, it will return a string and not throw, because it was so since the dawn of JS. It's totally false for random "host objects" with a [[Call]] in ES5, per spec and in at least some implementations. As you can tell in

Re: Calling toString on function proxy throws TypeError exception

On 10/27/15 9:14 AM, Boris Zbarsky wrote: On 10/27/15 4:35 AM, Claude Pache wrote: it is that, for any callable object, it will return a string and not throw, because it was so since the dawn of JS. It's totally false for random "host objects" with a [[Call]] in ES5, per spec and in at least

Re: Arrow function declaration

I would be inclined to agree. On Tue, Oct 27, 2015, 09:58 Федор Неживой wrote: > Yes, Isiah is right about the soul of this proposal. > Its a mostly a draft now, so yes this could be described better. If anyone > can help me with the right description I would be happy to

Re: Calling toString on function proxy throws TypeError exception

Notice that whatever we decide on the issue, functionProxy.toString() will work regardless, since you'd be getting the toString method itself through the membrane. functionProxy.toString will be a function proxy for the target.toString method. The invocation on the toString proxy with

Re: Syntax to get same object that method was called on (Easy method chaining)

I think this could be implemented with no regard to the function implementation, which would treat functions with and without a lexical `this` identically. @Caitlin I have similar doubts. Also, I don't particularly like the look of the `#` syntax. It looks too Perl-ish. On Mon, Oct 26, 2015,

Re: Calling toString on function proxy throws TypeError exception

Mark: considering that explicitly invoking a builtin prototype method, expecting a throw, to test for the [[Call]] internal slot, was the branding approach the committee agreed to preserve when it reaffirmed Symbol.toStringTag, as an alternative to `Object#toString.call`, I think Claude's point

Re: Calling toString on function proxy throws TypeError exception

> Le 27 oct. 2015 à 15:52, Mark S. Miller a écrit : > > Notice that whatever we decide on the issue, functionProxy.toString() will > work regardless, since you'd be getting the toString method itself through > the membrane. functionProxy.toString will be a function proxy

Re: Calling toString on function proxy throws TypeError exception

Non-membraned proxies are irreparably non-transparent. This case is not worth worrying about. On Tue, Oct 27, 2015 at 1:05 PM, Claude Pache wrote: > > > Le 27 oct. 2015 à 15:52, Mark S. Miller a écrit : > > > > Notice that whatever we decide on the

Re: Calling toString on function proxy throws TypeError exception

> On Oct 27, 2015, at 2:37 AM, Claude Pache wrote: > > > Naturally, I meant: > > ```js > Function.isGenerator = function (f) { > return typeof f == "function" && f.toString().match(/^function\s*\*/) != > null > } > ``` > > —Claude > >> >> That function will work

Re: Calling toString on function proxy throws TypeError exception

On 10/27/15 12:47 PM, Jordan Harband wrote: I think Claude's point ("The expectation is not that `F.p.toString` will always return something useful; it is that, for any callable object, it will return a string and not throw, because it was so since the dawn of JS.") is the one that convinces me.

Map literal

I'm using Maps a lot now and I was thinking why there is no "easy" way of declaring them like objects and arrays. I'm sure I'm not the first one who came up with the idea of having Map literal declaration. There are many ways we can introduce new syntax for declaring Maps via a literal syntax

Re: Calling toString on function proxy throws TypeError exception

> Le 27 oct. 2015 à 18:41, Allen Wirfs-Brock a écrit : > > > That said, I think it is plausible that the predicate in step 2 of > http://tc39.github.io/ecma262/#sec-function.prototype.tostring > could be

Re: Map literal

I agree this is pretty important. Using actual maps really frees up a lot of complexity, but the syntax is cumbersome to say the least. Whatever the decided syntax, bare words as string keys is a really bad idea IMO. The key syntax should be parsed as an expression, like the values are, and like

Re: Map literal

On Wed, Oct 28, 2015 at 8:36 AM, Alexander Jones wrote: > I agree this is pretty important. Using actual maps really frees up a lot of > complexity, but the syntax is cumbersome to say the least. > > Whatever the decided syntax, bare words as string keys is a really bad idea > IMO.

Re: Syntax to get same object that method was called on (Easy method chaining)

@Erik my bad I'm wrong, `..` works fine with a method returning a number, its only for a Number literal On Tue, Oct 27, 2015 at 12:24 PM, Isiah Meadows wrote: > I think this could be implemented with no regard to the function > implementation, which would treat functions

Re: Map literal

fwiw, my Object.entries proposal ( https://github.com/ljharb/proposal-object-values-entries ) would allow you to do: `new Map(Object.entries({ a: 'b', b: 'c' }))`. On Tue, Oct 27, 2015 at 4:36 PM, Alexander Jones wrote: > I agree this is pretty important. Using actual maps really

Re: Map literal

True, but easy to mess up and only be treated to a runtime error. Three nested brackets at the start and end could definitely be better, and this just encourages people to use POJSOs instead. Also not a very uniform interface if you look at how to construct a Map, Set or Immutable.List at present,

Re: Map literal

Quite verbose, harder to optimize and only supports string keys. On Wednesday, 28 October 2015, Jordan Harband wrote: > fwiw, my Object.entries proposal ( > https://github.com/ljharb/proposal-object-values-entries ) would allow > you to do: `new Map(Object.entries({ a: 'b', b:

Re: Arrow function declaration

The proposal is about more concise function definitions as well as lexical binding. The proposal would look a little more like this, if I understand correctly: ```js function sumOfSquares(list) => list.map(x => x * x).reduce((x, y) => x + y, 0) // Or: function sumOfSquares(list) =>

Re: Arrow function declaration

Yes, Isiah is right about the soul of this proposal. Its a mostly a draft now, so yes this could be described better. If anyone can help me with the right description I would be happy to collaborate on this. This feature is not just one more sugar. I really miss it in every day development. Hope I

Re: Calling toString on function proxy throws TypeError exception

> Le 27 oct. 2015 à 14:14, Boris Zbarsky a écrit : > > On 10/27/15 4:35 AM, Claude Pache wrote: >> it is that, for any callable object, it will return a string and not throw, >> because it was so since the dawn of JS. > > It's totally false for random "host objects" with a