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

Hello, it's me, long-time lurker and person whose opinion shouldn't matter. I find the syntax and semantics of this to be nothing I've ever had a use case for, and I think it would make the language more complicated without much benefit. But if JS really wanted something like this, I'd prefer to

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

Why? It isn't valid syntax now so it can't be misunderstood by parser. On Oct 26, 2015 7:48 AM, "Edwin Reynoso" wrote: > That's not possible @Eric > > On Mon, Oct 26, 2015 at 2:20 AM, Eric Suen > wrote: > >> with >> >> obj.(doSomething(),

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

with obj.(doSomething(), doSomething2()); you don’t need to introduce new operator. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Default call constructor behavior

> Le 26 oct. 2015 à 03:59, Isiah Meadows a écrit : > > According to the current call constructor proposal, the behavior for > classes without call constructors is to unconditionally throw. > Shouldn't this be changed to automatically calling the constructor? I > see this

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

More like Foo()# // SyntaxError Foo.bar()# // Foo Foo.bar.baz()# // Foo.bar The super property thing is a harder problem. They would always return `this` i guess, but I'm not sure if chaining a super method should lookup a method in the prototype first, or instance first > On Oct 26, 2015,

Re: Calling toString on function proxy throws TypeError exception

> 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 treating a function proxy as a builtin callable, > rather than a function written in JS,

Re: Calling toString on function proxy throws TypeError exception

Only because typeof f === 'function' divides the world into callables and non callables. On Oct 26, 2015 3:20 PM, "Allen Wirfs-Brock" wrote: > > > > On Oct 26, 2015, at 11:20 AM, Mark Miller wrote: > > > > I like the idea a function proxy is more

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

@CaitIin see what your saying which would simplify things: `foo()#` returns `undefined` `foo.bar.call(baz)#` returns `foo` (correct?) `baz.quux = foo.bind(bar)` returns `baz` (correct?) and as for property accessors I think they should throw, it should only be for function calls, because why

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

`foo()#` would best throw an early error — theres no syntactically apparent `this`, so cascading doesn’t add anything useful. `foo.bar.call(baz)#` would return `foo.bar`, as the method being invoked is `call`, and `foo.bar` is the `this` for that method. `baz.quux = foo.bind(bar); baz.quux()#`

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

@Caitlin yea that's correct, but you didn't compare what I had typed out: `foo()#` returns `undefined` `foo.bar.call(baz)#` returns `foo` (correct?) `baz.quux = foo.bind(bar)` returns `baz` (correct?) @Erik but what happens when a method returns a Number `5..toString();` // works in ES5

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

There used to be a proposal in the ES5 timeframe for cascade expressions. This is what later made it into Dart using the `..` syntax. For ES the syntax was using `.{`. The proposal never gained a lot of traction so it was removed. https://github.com/google/traceur-compiler/issues/405 On Mon,

Re: Arrow function declaration

Федор Неживой schrieb: I'm looking for a champion for https://github.com/gyzerok/ecmascript-arrow-function-declaration Your proposal doesn't seem to solve the problem that you gave in your rationale. Let me paraphrase: You've got curried functions, and you want to partially apply them

Re: Default call constructor behavior

A downside of specifying a default like this is that adding a "call constructor" (can we think of a better name for this?) to an existing class would become a breaking change for users of that class. On Mon, Oct 26, 2015 at 8:49 AM Isiah Meadows wrote: > I was using

Re: Default call constructor behavior

I was using F.p.partial as merely an example. There are others I could have used. The main problem related to 4 is `apply`ing a constructor without needing to bind it. I rarely have the use case for F.p.partial myself, unless I'm experimenting with point free style (which is admittedly not very

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

I love cool syntactic innovations as much as the next guy. I'm sure there are a bunch sitting out there waiting to be discovered that will make us all sit back in awe. But it's not a particularly new insight to observe that especially if they introduce no new basic functionality and are just

Re: Calling toString on function proxy throws TypeError exception

> On Oct 23, 2015, at 6:43 AM, Claude Pache wrote: > > Almost every method found on `Function.prototype` "works" (or, at least, does > not throw a TypeError before trying to work) if and only if the target is > callable, or if and only if `typeof` applied to the target

Re: Calling toString on function proxy throws TypeError exception

I like the idea a function proxy is more encapsulating of its implementation than a function is. I also like the idea of treating a function proxy as a builtin callable, rather than a function written in JS, and return something like "function () { [function proxy] }" as Tom suggested or