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

Wed Oct 28 00:06:01 UTC 2015

@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 <isiahmeadows at gmail.com>
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 <caitpotter88 at gmail.com> 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 <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>
>> 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> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20151027/421e4e93/attachment.html>