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

[Caitlin Potter]

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 <eorroe at gmail.com> 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 <rtm at gol.com> 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151026/e928547e/attachment.html>