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
