`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()#` would return `baz`, yes. But, here’s the issue — it still doesn’t deal with callable objects with a lexical `this`, like arrow functions — and of course it doesn’t help much with bound functions. So, you can get misleading results with the cascading operator in JS, even in this dramatically simplified form. I don’t really expect that this proposal (with these gotchas) would be able to reach consensus and make it into a ratified specification. > On Oct 26, 2015, at 6:21 PM, Edwin Reynoso <[email protected]> wrote: > > @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 because the first `.` is for the decimal > > On Mon, Oct 26, 2015 at 6:16 PM, Caitlin Potter <[email protected] > <mailto:[email protected]>> wrote: > > 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, at 6:11 PM, Edwin Reynoso <[email protected] > <mailto:[email protected]>> wrote: > >> @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 after getting a property would you want to >> get the object back? The only reason I can think of is that its a getter and >> it does have a side effect (which in my opinion its just a bad idea) >> >> Take `[].length` why would you actually type out `.length` if you don't want >> it, compare to a function call which it should have a side effect. >> >> So these should throw: >> >> `[].length#` // throws >> `({ foo: 3 }).foo#` // throws >> >> @Adam >> >> I'm not sure about that, not sure if `with()` would be brought back to "good >> use" (I kind of always liked it) but interesting thought >> >> BTW I don't think you need the preceding `.` in `with` statements >> >> @Eric >> >> Other languages having `#` as comments, doesn't matter >> >> I don't really like that syntax because this is how it would look if you had >> it in different lines, but that's not really up to me: >> >> ```JS >> obj.( >> f1(), >> f2() >> ); >> ``` >> >> Compare that to: >> >> ```JS >> obj >> .f1() >> #f2() >> ``` >> >> There's extra parentheses and having a comma, also there's already a comma >> operator, not sure if that will confuse things. >> >> @Erik >> >> That's a nice syntax I suppose >> >> @Bergi >> >> No, the method being called is actually `bar`, but using `call` calls the >> method `bar` with a different `this` value. >> >> @Bob >> >> I see what your saying that's actually an idea I had first, just not that >> syntax, but that's true if the APIs are ones you wrote, there are lots of >> APIs that are out there already and may have functions that return other >> values that you may or may not need. >> >> Yea you could use that chainify function easily if you were the one writing >> the API, but like I said above, there are methods already that may return >> something, and what they return is useful, but sometimes you may not need >> them. They could have a parameter as to what to return but that just >> complicates things, having a way to do this in the languages means 2 things: >> >> 1. No API methods have to be changed, to do accomplish this >> 2. APIs can then return something else, and JS can always provide a way to >> return the object back, instead of the API having to do it. >> >> On Mon, Oct 26, 2015 at 1:05 PM, Bob Myers <[email protected] >> <mailto:[email protected]>> wrote: >> 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 sugar, then such >> innovations have to solve a real pain point, not have simple user-side >> solutions, and not eat too much into the syntactic space for better future >> ideas. >> >> Here, I'm really having a hard time trying to figure out what's so painful >> about >> >> obj.foo(); >> obj.bar(); >> >> that would lead us to introduce `.{` or `..` or `#.` to solve the problem of >> typing `obj` twice. The resulting code (whether `obj.foo()..bar()` or >> `obj.{foo(); bar()}` or `obj.foo()#.bar()`) is neither more writable, nor >> more readable, nor more maintainable, nor more provably correct. On the >> contrary. All are more obtuse, obscure, and bug-prone. >> >> As a semi-ridiculous example of a seemingly useful new syntactic structure, >> let me introduce the `<#>` syntax. This is a mechanism for writing an >> expression, enclosed in `<>`, which throws away its value and instead >> evaluates to a value within the expression prefixed by a (tightly-bound) `#` >> operator. So, for instance, I can write >> >> return <foo(#5)>; >> >> In other words, call `foo(5)`, but deem the expression to evaluate to 5 and >> return that. >> >> The proposed `obj.foo()#.bar()` could be written as >> >> <#obj.foo()>.bar(); >> >> I have no trouble imagining that this syntax could result in some more >> compact code, but I doubt if it would be more writable or readable. It's >> syntactic over-think. >> >> Another criteria for accepting new syntax ideas is that they should be >> general and compositional. In other words, they should solve more than one >> problem. Solving the single problem of "take a method call on an object and >> fix it up so that later stuff in the expression refers to the object instead >> of the result of the method call" does not meet this criteria. >> >> I mean, if you want to write chainable functions, then just write them that >> way. >> >> If you have non-chainable functions, and you want to make them >> chainable/cascadable, it's not a real problem to chainify a function: >> >> function chainify(fn) { >> return function() { >> void fn.apply(this, arguments); >> return this; >> }; >> } >> >> obj.doSomethingChained = chainify(obj.doSomething); >> obj.doSomethingChained().doSomething2(); >> >> If you have a whole set of APIs you want to chainify, you could take a leaf >> from the `promisifyAll` paradigm, and do it all at once: >> >> chainifyAll(obj); >> >> which would create methods xxxChained for all methods on the object. >> >> -- >> Bob >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
