Syntax to get same object that method was called on (Easy method chaining)
Caitlin Potter
caitpotter88 at gmail.com
Mon Oct 26 22:28:27 UTC 2015
`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 <eorroe at gmail.com> 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 <caitpotter88 at gmail.com <mailto:caitpotter88 at gmail.com>> 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 <eorroe at gmail.com <mailto: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 <mailto: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 <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151026/f6d53391/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151026/f6d53391/attachment.sig>
More information about the es-discuss
mailing list