@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 <[email protected]> wrote: > 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, 18:28 Caitlin Potter <[email protected]> wrote: > >> `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]> >> 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]> 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]> 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] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
